Begränsningarna i TCP (Transmission Control Protocol) och UDP (User Datagram Protocol) för transport av signaltrafik ledde till utformningen av ett nytt transportprotokoll inom IETF (Internet Engineering Task Force). SIGTRAN-arbetsgruppen utvecklade Stream Control Transmission Protocol (SCTP) [1, 2]. SCTP var först avsett att transportera telefonisignaler över ett opålitligt nät såsom ett IP-nät [3]. Protokollet har dock utformats så att SCTP kan användas som ett allmänt meddelandebaserat transportprotokoll. Vi jämför SCTP:s beteende och prestanda med befintliga transportprotokoll. Våra simuleringar visar att Head of the Line (HOL)-blockering, som allmänt anses vara TCP:s stora begränsning vid transport av signaltrafik, inte medför någon betydande prestandaminskning även under tung last. Vi upptäckte också några problem när det gäller fragmentering av transportlager. För att kunna göra en rättvis jämförelse behövde vi ett applikationslagerprotokoll som kunde köras ovanpå alla de olika transportprotokoll vi ville analysera, nämligen SCTP, UDP och TCP. Vi valde Session Initiation Protocol (SIP) [4]. SIP är ett program-lager protokoll för att skapa, ändra och avsluta sessioner. Den grundläggande driften av SIP är inte beroende av transportprotokollet i lägre skikt, vilket gör det till ett idealiskt val att jämföra olika transporters prestanda. I SIP-specifikationen [4] beskrivs hur protokollet fungerar över TCP [5] och över UDP [6]. TCP ger tillförlitlig överföring av byte i beställningssyfte, medan UDP inte garanterar vare sig tillförlitlighet eller leverans i beställningen. Vi definierade [7] hur SIP kan köras ovanpå SCTP. Även om det redan finns implementeringar av telefonsignalering protokoll som ISUP på toppen av SCTP, vi känner till inga SIP-implementationer som använder SCTP. Resten av denna artikel är organiserad enligt följande. Vi introducerar SCTP respektive SIP. Vi introducerar också simuleringsmiljön. Med hjälp av simuleringar jämför vi SCTP, UDP och TCP som transportprotokoll för SIP. Slutligen redogör vi för några slutsatser. Stream Control Transmission Protocol (SCTP) [1] är ett transportprotokoll som är anpassat för transportsignalering. SCTP ärver alla sina mekanismer för trängsel och flödeskontroll från TCP, men innehåller ett antal förbättringar som syftar till att göra det till en effektivare signaltransport än TCP. SCTP är ett anslutningsinriktat transportprotokoll. I SCTP:s terminologi kallas en förbindelse för en förening. En sammanslutning inrättas genom ett fyrvägshandskakning i motsats till det trevägshandskakning som TCP har genomfört. Med ytterligare ett meddelande i SCTP handskakningen, visas i bild. 1, skyddar servrar mot Denial of Service (DoS) attacker med spoofed IP-adresser. I TCP utnyttjar SYN-översvämningsattacken bristen på en statslös bekräftelse av möjligheten att återvända. SCTP-mottagaren skickar, efter att ha tagit emot ett INIT-meddelande, tillbaka ett slumpmässigt nummer, kallat en cookie, i ett INIT ACK-meddelande. Denna mottagare allokerar inte några resurser till denna SCTP-förening förrän den får samma cookie i COOKIE ECHO-meddelandet. Därför tilldelas resurser endast när det säkerställs att den part som påstås sända INIT-meddelandet verkligen är villig att upprätta en SCTP-förening. COOKIE ACK-meddelandet informerar helt enkelt avsändaren om att COOKIE ECHO-massagen har mottagits framgångsrikt och att den innehöll en giltig cookie. De två sista meddelandena från fyrvägshandskakningen kan redan medföra användardata. Med denna data Grisgybacking, SCTP har samma anslutning-etablering fördröjning som TCP, nämligen en tur och retur tid. För att öka robustheten är servrar ofta utrustade med flera nätverksgränssnitt. Sådana servrar sägs vara multihomed. SCTP var designad med multihoming i åtanke. Under föreningens etablering kan en SCTP-slutpunkt förse sitt IEEE-nätverk • september/oktober 2003 41 deltagare med en förteckning över IP-adresser eller värdnamn. En destinationsadress markeras som primär och används av SCTP:s slutpunkt för att skicka data till deltagaren under normala omständigheter. Om den primära måladressen blir otillgänglig, börjar slutpunkten skicka trafik till en annan adress på den lista som tillhandahålls av motparten. Denna funktion tillåter SCTP-föreningar att överleva vissa nätverksfel som skulle göra en TCP-anslutning kollaps. Liksom UDP är SCTP ett meddelande-orienterat protokoll medan TCP är stream-orienterat. SCTP levererar meddelanden till applikationen, medan TCP levererar en ström av bytes. Meddelandeorienterade protokoll som SCTP och UDP förenklar programtolkar. När dessa transportprotokoll levererar ett meddelande till applikationen innehåller det ett enda signalmeddelande. Omvänt, för att extrahera ett signalmeddelande från strömmen av byte som mottagits över TCP, är det nödvändigt att genomföra tillämpningsnivå utformning. Varje meddelande i applikationsskiktet som transporteras av SCTP kallas en databit. SCTP buntar DATA bitar så att ett enda IP datagram kan bära flera DATA bitar, öka nätverkseffektiviteten. Figur 2 visar formatet för ett SCTP-meddelande när buntning utförs. SCTP tillhandahåller multiplexing och demultiplexing av DATA bitar inom en sammanslutning. En enda förening kan innehålla flera vattendrag, där varje bäck identifieras genom sitt stream id. Antalet strömmar i båda riktningarna bestäms under fyrvägshandskakningen (Fig. 1).................................................................. Varje DATA bit tillhör en ström; strömmar levereras till applikationen oberoende av varandra. Denna oberoende leverans av strömmar löser Head of the Line (HOL) blockerande problem som finns i TCP. HOL-blockering uppstår när data tillhörande flera logiska sessioner interleaved över en enda TCP-anslutning. Detta problem är vanligt i HTTP/1.1, där bilder och HTML från en enda server hämtas i en TCP-anslutning. Om ett segment för en av bilderna går förlorat, måste leveransen av meddelanden för HTML-texten vänta tills bildsegmentet har återöverförts. Således, en logisk session blockerar på grund av förlust i en annan, orelaterade en. Liknande problem uppstår om flera signalsessioner multiplexas på en enda TCP-session mellan två signalservrar. Med SCTP skulle varje programnivåsession tilldelas sin egen ström, så att förlusten av ett paket i en ström inte påverkar utvecklingen i andra strömmar. En SCTP-förening kan innehålla flera typer av strömmar, som var och en erbjuder olika tjänster. Basen SCTP specifikation [1] definierar två tjänster: tillförlitlig beställd leverans och tillförlitlig obeställd leverans. Utökningar till SCTP [8] beskriver en otillförlitlig leveranstjänst. I den beställda tjänsten tar mottagaren emot meddelanden i samma ordning som de skickades av avsändaren. Den obeställda tjänsten levererar meddelanden till mottagaren så snart de tas emot från nätverket, oavsett i vilken ordning avsändaren producerade dem. Det är viktigt att notera att en viss tjänst tillhandahålls varje databit. Därför kan en DATA bit inom en ström levereras i ordning, medan en annan DATA bit inom samma ström använder obeställd leverans. Även om en förening innehåller flera strömmar utför SCTP flödes- och trängselkontroll för hela föreningen. Detta gör att vi kan använda beteendet hos all trafik inom föreningen som ingång till flödes- och trängselkontrollmekanismerna, som är baserade på de som används av TCP. SCTP flödesreglering baseras på TCP SACK [9]. SACK är en förlängning till TCP som använder selektiva ACK utöver de kumulativa ACK. Den kumulativa ACK bekräftar mottagandet av alla data inom en anslutning med ett sekvensnummer mindre än ett visst nummer, medan den selektiva ACK erkänner mottagandet av icke sammanhängande intervall av sekvensnummer. Den kumulativa ACK är den viktigaste mekanismen för att upptäcka paketförluster i TCP. Om en TCP-slutpunkt tar emot paket 1, 2, 3, 5 och 7, kommer den att skicka ACK (1), ACK (2), ACK (3), ACK (3) och ACK (3) igen. När avsändaren får ACK (3) flera gånger, vet den att paket 4 gick förlorat och därför måste överföras på nytt. Avsändaren vet dock inte vilka paket med ett högre sekvensnummer än 4 som kom fram framgångsrikt till kamraten och vilka som också gick förlorade. Om mottagaren hade använt SACK TCP-alternativet skulle den ha returnerat ACK (3)-SACK (5) och (7). Med denna information kan avsändaren sända om inte bara paket 4, utan även paket 6. Prestandamätningar [10] visar att TCP SACK återhämtar sig bättre än TCP Reno och New Reno från flera förluster i ett enda TCP-fönster. Det finns bara två skillnader mellan TCP SACK och SCTP. De 40 byte som finns tillgängliga för TCP-alternativ kan endast medföra högst fyra SACK-block per TCP-segment, medan SCTP inte fastställer någon gräns för antalet SACK-bitar i ett paket. För det andra använder TCP SACK informationen i SACKs endast för att återföra förlorade segment, medan SCTP använder denna information för att utföra både flödes- och överbelastningskontroll. SCTP använder SACKed DATA bitar för att öka sin trängsel fönster, medan TCP SACK inte. På så sätt uppnår SCTP en något högre fönstertillväxthastighet än TCP SACK under överbelastning när både DATA-bitar och SACKs går förlorade. SCTP är "TCP-vänlig", dvs. använder ungefär samma bandbredd som en TCP-anslutning under samma nätverksförhållanden. Detta är inte förvånande eftersom både SCTP och TCP använder samma fönsterbaserade överbelastningskontroll. Avsändaren implementerar ett trängselfönster (cwnd) som begränsar antalet byte som kan injiceras i nätverket vid en given tidpunkt. Den takt med vilken cwnd växer beror på tillståndet i anslutningen. Om ingen överbelastning upptäcks, fördubblas den långsamma startalgoritmen cwnd varje gång ett helt datafönster är erkänt. Vid paketförlust ökar algoritmen för undvikande av överbelastning långsammare, nämligen linjärt snarare än exponentiellt.  SIP är ett textbaserat programlagerprotokoll som används för att upprätta multimediasessioner. SIP kan använda alla transportprotokoll. För närvarande används UDP mest, men de flesta genomföranden stöder nu både UDP och TCP. SIP-slutpunkter förhandlar om parametrarna för en viss multimediasession med hjälp av ett erbjudande/svarsmodell. En slutpunkt ger en sessionsbeskrivning – vanligtvis med Session Description Protocol (SDP) [11] – som innehåller nätverksadressen och portnumret där den vill ta emot media och medieformatet, beskrivet av röst- och videokoderna som ska användas. SIP levererar detta erbjudande till motparten, som sedan svarar med sin egen sessionsbeskrivning, svaret, i ett annat SIP-meddelande. När båda endpoints har utbytt sina sessionsbeskrivningar, kan de skicka media till varandra. SIP-meddelanden bär sessionsbeskrivningar på samma sätt som e-postmeddelanden bär bilagor, med MIME [12]. SIP etablerar sessioner mellan användaragenter. Förutom användaragenter definierar SIP mellanliggande nätverksenheter som kallas SIP-proxies. En SIP-proxy tar emot ett meddelande från en user agent eller från en annan proxy och vidarebefordrar det till nästa SIP hop, som kan vara ännu en proxy eller destinationsanvändaren agent. Figur 3 visar det typiska SIP-meddelandeutbytet för att upprätta en session. Figuren innehåller två användare, anropare och anropare, och en proxy. Uppringaren skickar en INVITE-förfrågan som anger att den uppringde är villig att upprätta en session med den uppringde. Anroparen får sedan två svar, ett "100 Försök" svar följt, om anroparen svarar, av ett "200 OK" svar. Den förra visar att begäran har mottagits; den uppringda använder "200 OK" för att indikera att hon är villig att delta i denna multimedia session. (Klockan har en lista över felkoder för att indikera olika fel.) SIP baseras på en HTTP-liknande begäran/svar transaktionsmodell och därför SIP svar följer samma format som används i HTTP. Efter mottagandet av "200 OK" svar, ringer upp en ACK begäran om att bekräfta mottagandet av detta svar. SIP använder två tvåvägs handskakningar för att etablera en session: "INVITE-100 Testing" och "200 OK-ACK". Det första handslaget är mellan närliggande SIP noder, med varje svar som genereras av nästa hop. Det andra handslaget ligger mellan begärans ursprung och dess slutdestination, dvs. två användaragenter. Svaret "200 OK" går fortfarande igenom alla hopp, medan ACK-begäran kan kringgå mellanliggande hopp och gå direkt från anropare till anrops- eller proxyservrar kan be att vara i sin väg. På bild. 3, proxyn svarar på INVITE begäran som mottagits från uppringaren. Därför används ett enda transportprotokoll för denna typ av handslag. I den andra handskakningen genereras svaret av SIP-användaragenten på distans. Proxies i sökvägen överför helt enkelt svaret. Således kan end-to-end handskakningar innebära flera transportprotokoll. I exemplet med Fig. 3, "200 OK-ACK" handskakning använder två olika transportprotokoll: TCP från anropare till proxy och UDP från proxy till anropare. Denna artikel fokuserar på "INVITE-100 Testing" hop-byhop handskakning. Vi har valt detta handslag eftersom trafikbeteendet mellan två olika noder bara beror på ett enda transportprotokoll. Genomföra olika transportprotokoll mellan samma noder under samma nätförhållanden visar hur effektivt varje transportprotokoll är. Men i end-to-end handskakning påverkar olika transportprotokoll trafikbeteendet. Ett paket som släpps av UDP, till exempel, kan utlösa en program-lager retransmission över en TCP-anslutning. Vi kommer att ha denna situation i Fig. 3 om ACK-begäran läggs ned i UDP-benet. Den som ringer måste skicka samma Ak över sin TCP-anslutning. Dessa interaktioner mellan applikationsskikt och transportskiktets tillförlitlighet ligger utanför denna artikels tillämpningsområde. För otillförlitliga transportprotokoll genomförs handslaget hop-by-hop med hjälp av timeouts och program-layer retransmissioner. Klienten åter sänder INVITE tills "100 försöker" svar tas emot. Servern sänder tillbaka "100 Testing" varje gång den får en återsändning av INVITE. INVITE förfrågningar återsändas först efter 500 ms, med intervallet fördubblas efter det. Kunderna anser vanligtvis att nästa hopp är ouppnåeligt om inget svar har mottagits efter den sjätte vidaresändningen. Om Hop-by-hop SIP handskakning passerar en tillförlitlig transportanslutning som TCP, skickar kunden INVITE över transportanslutningen och servern returnerar "100 försöker" svar över samma anslutning. Transportskiktet åtar sig uppgiften att leverera meddelandet till nästa humle, så att det inte behövs någon vidaresändning i lager. SIP över SCTP -SIP över SCTP följer reglerna för TCP, så att förfrågningar och svar skickas över samma sammanslutning [7]. Vi kartlägger all SIP-trafik på en enda ström med SCTP obeställd tjänst, så att inkommande SIP-meddelanden levereras till applikationen i samma ordning som de anländer från nätverket, oavsett i vilken ordning de skickades. Detta hjälper till att undvika HOL blockeringsproblem som finns i TCP. (Ett alternativ som diskuteras i [7] är att tilldela varje SIP-session sin egen SCTP-ström. Detta undviker också HOL-blockering och kan snabba upp matchande förfrågningar om tillståndsposter, men kräver mer ström resurser.)
Flera simuleringsbaserade studier har jämfört end-to-end-förseningar av TCP och SCTP, men resultaten är tvetydiga: REF jämför fördröjningen av SIP-meddelanden som transporteras via UDP, TCP respektive SCTP.
Evaluation of transport protocols for the session initiation protocol
{'venue': None, 'journal': 'IEEE Network', 'mag_field_of_study': ['Computer Science']}