NO328057B1 - Et system for media nettverkstjenester - Google Patents

Abstract

Et system og metode for utstyr og tjenester for å tilby en forbedret global transport av IP-pakker. Et globalt virtuelt nett med garantert kapasitet brukes til å transportere nevnte IP-pakker. Et antall applikasjons-spesifikke, selektive Videresendings-enheter benyttes for å detektere og videresende utvalgte trafikktyper til dert nevnte virtuelle nettverk. De applikasjons-spesifikke, selektive videresendingsenhetene kan implementeres basert på analyse av IP-pakker eller ved kontrollprotokoller som SIP/H.323

Description

Et system for media nettverkstjenester

Bakgrunn for oppfinnelsen

I bruksmodellen som dominerer Internett i dag som vist i figur 1, er kommunikasjonsutstyr (1) som produserer data-strømmer lokalisert i kanten av nettverket. Data sendes fra avsenderendepunkt til mottakerendepunkt ved hjelp av nettverket. Nettverket omfatter lokale nett ved avsender og ved mottaker (13), en eller flere Internett-tjenesteleverandører (ISP, 10) og en eller flere transportnett (11).

Lokale nettverk (13) implementerer sikre kommunikasjons-omgivelser som typisk har private adresser og en brannvegg mot resten av Internett. Lokale Internett tjenesteleverandør-nettverk (10) aggregerer et antall lokale nettverk og bruker transportleverandører (11) til å nå hverandre.

Datapakker entrer nettverket fra endesystemene, typisk via et socket-grensesnitt. I denne modellen er socket identifisert ved pentuppel kombinasjonen av avsenderadresse, mottaker-adresse, avsender-portnummer, mottaker-portnummer og protokolltype. Pakkene består av to deler: et pakkehode og en nyttelast. Pakkehodet inneholder kontrollinformasjon, mens nyttelasten inneholder høyere nivåers (for eksempel applikasjonsnivå) data. Pakkehodet identifiserer tidligere omtalte pentuppel.

Datapakker videresendes mellom videresendingsanordningene (20) hopp-for-hopp ved bruk av informasjonen i pakkehodet. Selv om ytterligere funksjonalitet kan implementeres i et nettverk, så er bare denne hopp-for-hopp-videresendingen frem til mottakeren implementert universelt i Internett. Derfor er nettverksfunksjonaliteten som implementeres i et endepunkt og de tilhørende lokale nettverkskomponentene relatert til adressering, som inkluderer:

a) Oversettelse av symbolske navn til nettverksadresser

b) Støtte for traversering av nettverksadresseoversettere (Network Address Translator, NAT) og traversering av

brannvegger.

Dette enkle grensesnittet tillater ikke endepunktet å velge ende-til-ende-nettverkssti. Bare mottakeren kan velges, og nettverket velger selv veien for pakken. Typisk må pakken traversere multiple administrative autoriteter langs veien.

Internett implementerer såkalt beste-evne-tjeneste til sine brukere. Dette betyr at pakker transporteres fra node til node mot mottakeren. De kan midlertidig lagres i transitt-nodene og avvente tilgjengelig nettverkskapasitet for å fortsette sin reise (mellomlagring/bufring). Nodene kan kaste en pakke, noe som typisk skjer dersom en node mottar flere pakker enn den for øyeblikket kan videresende og buffer-kapasiteten er overskredet. Ingen melding gis til avsender av pakken.

Mange applikasjoner er interaktive eller båndbredde-krevende, og har spesielle nettverkskrav slik som lav forsinkelse eller lavt pakketap. Disse applikasjonene inkluderer blant andre spill, forretningsinformasjonsstrømmer og multimedia-kommunikasjon. Den tradisjonelle Internettmodellen er utilstrekkelig for disse applikasjonene. Avansert endepunkt-utstyr kan oppleve redusert kvalitet på grunn av kø og pakketap.

Tiltak som kan forbedre nettverkskvaliteten og tilgjengelig-heten inkluderer etablering av fysiske eller virtuelle private nett. Store bedrifter kan leie eller etablere nettverkskapasitet for å koble sammen sine lokasjoner innenfor bedriften, til en betydelig kostnad.

Videre kan man påvirke pakkestien ved å benytte overlagrede eller peer-to-peer-arkitekturer. Overlagrede nett og peer-to-peer-nett kan ikke forbedre nettkvaliteten med mindre nettresursene kan tilby kapasitetsgarantier, som typisk ikke er tilfelle.

Nylig har noen Internett-tjenesteleverandører (ISP) utvidet sine nettaksess og Virtuelle Private Nett (VPN) -tjenester ved å tilby nye nettverkstjenestemodeller.

En modell er å tilby infrastruktur for midlertidig data-lagring (caching) for å forbedre storskala en-til-mange dataoverføring. Denne modellen sparer på overførings-kapasitet, men den forutsetter toleranse for forsinkelsen og er ikke egnet for interaktiv, sanntids-kommunikasjon.

En annen nettverkstjenestemodell er å tilby infrastruktur med garantert overføringskapasitet til kunder som er geografisk spredt, sammen med tilhørende privatnett-vedlikeholds-tjenester. Slike tjenester skiller seg fra VPN ved at det ikke kan gis garanti for overføringskapasitet og forsinkelse i nettet, og kunden trenger ikke å ha driftpersonell ansatt. Modellen er imidlertid begrenset til der tjenesteleverandøren har fysisk infrastruktur tilgjengelig, og kan ikke utvides til samband med vilkårlige mottakere.

Noen leverandører bygger sin forretningsmodell på omfattende "Border Gateway Protocol" (BGP) -peering-avtaler med lokale Internett-tjenesteleverandører (ISP), og utvider ytelsen til sine hosting-tjenester. Denne metoden forbedrer nettverks-tjenestekvalitet kun lokalt.

Avslutningsvis leier noen tilbydere nettverkskapasitet, eller etablerer den selv der det trengs, og tilbyr en tjeneste med ende-til-ende-garantert overføringskapasitet. Dette alternativet gir svært god nettverksinfrastruktur, men er grovdelt og dyrt og er derfor bare tilgjengelig for de mest betalingsdyktige bedriftskunder. Kommunikasjon med vilkårlige mottakere er ikke mulig.

I WO 2006/043139 "Address Modification in Application Servers" presenteres adressemodifikasjon i

applikasjonstjenere ved å plassere et internettprotokoll-multimedia-undersystem oppe på et pakkesvitsjet nettverk for tredje generasjons multimediatjenester. Dokumentet beskriver fremgangsmåte, tjener og kontrollutstyr for privat nummerplanendring, tjenestebærers aksesskodeendringer, anropviderekopling, tjenestenummerendringer og nummerportabilitet. Denne løsningen er begrenset til signaleringsfunksjonalitet, og omfatter ikke dataplan eller nettkvalitet.

"A Practical Transit Mapping Service" (Draft-jen-apt-00.txt) Version 01 utgitt 2007.11.18 fra Routing Research Group (RRG) er et utkast som er fremmet for IETF (Internet Engineering Task Force) som beskriver mapping av adresseområder for transittnettverk. Denne arkitekturen omfatter ikke lokalnett, og behandler all trafikk likt.

I US 2003/0118036 "Routing Traffic in a Communications Network" presenteres ruting av pakker i et system av autonome, dvs uavhengige nettverksystemer basert på BGP (Border Gateway Protocol).

I WO 2007/011927 "Dynamic Enforcement of MPLS-TE Inter-Domain Policy and QOS" beskrives dynamisk ruting basert på LSP

(Label Switched Path) for ruting mellom domener. Policy trigges ved et PDP (Policy Decision Point). Problemstillinger ved å levere tjenestekvalitet (QoS) i form av båndbredde adresseres. En løsning for MPLS-svitsjing presenteres ved at hver ruter har en videresendingsseksjon hvor en bestemmer fra en "label" i den innkommende pakken en referanse til en tabell med denne informasjonen slik at nettverksegressen kan gjøre en viderekoplingsavgjørelse.

I EP 1 708 408 "A System and Method of Ensuring Quality of Service in Virtual Private Network" presenteres et system og en fremgangsmåte for sikring av nødvendig tjenestekvalitet (QoS). Her beskrives sentraliserte ressurskontrollere for håndtering av ressurser for private nettverk som er plassert slik at det utveksles topografisk informasjon.

Tjenestekvalitet i Internett

Ved å erkjenne svakhetene til "beste-evne" -Internettjeneste, har forskningsmiljøet foreslått Tjenestevkvalitet- (QoS) modeller for Internett. I IntServ [RFC1633], kan nett-ressurser reserveres ende-til-ende ved å benytte en spesiell signaleringsprotokoll som heter RSVP. Ressursene er reservert per flyt, langs standard ruting sti. Slik per flytreservering skalerer dårlig i Internett der millioner av slike strømmer flyter samtidig, og metoden blir sjelden benyttet i praksis. DiffServ [RFC2475] er et rammeverk for tjenestekvalitet for differensiering mellom ulike tjenesteklasser. DiffServ skalerer godt og kan brukes til å tilby en bedre tjeneste til bestemte segmenter av nettverkstrafikken, slik som for eksempel VoIP. Imidlertid tilbyr ikke DiffServ harde tjenestekvalitetsgarantier, kun prioritering av en gitt trafikktype foran en annen.

Begge de Internett-baserte tjenestekvalitetsrammeverkene har et betydelig problem ved at de trenger tjenesteavtaler mellom de administrative domenene. Videre vil en lokal Internett-tjenesteleverandør måtte garantere tjenestenivået til brukeren, uten å ha full kontroll over hvordan data er sendt til mottakeren. Dette har vist seg vanskelig i praksis, og IntServ og DiffServ er foreløpig primært brukt i private nettverk.

Nettverksvirtualisering

Nettverksvirtualisering er nylig foreslått som en metode for å etablere globale nettverkstjenester. I et arkitekturforslag som kalles CABO ("Concurrent Architectures are Better than One" [CABO]), kobler virtuelle nettverkslenker virtuelle rutere for å etablere et spektrum av samtidige internett. De virtuelle linkene er implementert ved hjelp av en av mange tilgjengelige teknologier som MPLS og IP-tunellering. Virtuelle rutere kjører som prosesser på fysiske rutere som eies og administreres av infrastrukturleverandøren. De virtuelle ruterne har sine integrerte ressurser som utgående køer og planleggere. Det er også mulig å koble virtuelle linker basert på infrastruktur som eies av ulike leverandører ved å bruke virtuelle rutere.

Forskjellen mellom infrastrukturleverandører og nettverks-tjenesteleverandører er et nytt konsept i CABO og gjør det mulig å implementere skreddersydde globale nettverkstjenester. Disse kan inkludere sikre nettverk, nettverk med tjenestekvalitet, og nettverk med forskjellig adressering og rutingløsninger som muliggjør til nå ukjente tjenester. CABO anbefaler også å ta i bruk et signaleringssystem for dynamisk etablering av virtuelle nettverkstopologier. Imidlertid er det vanskelig med dagens forretnings- og sikkerhetsmodeller i Internett å etablere CABO-baserte nett siden nettverks-operatørene ikke aksepterer tredjeparts adgang til deres kritiske infrastruktur.

Konferansetjenester i sanntid

Multimedia-konferansetjenester i sanntid har fått betydelig økt popularitet i den senere tid, spesielt innen audio (telefoni / tale over IP) -anvendelser. Typisk benyttes det et kontrollsystem basert på "Session Initiation Protocol", H.323 eller en proprietær protokoll, som for eksempel Skype, for å etablere en forbindelse mellom endepunktene. Endepunktene koder inn media (audio, video, tekst for kortmeldinger, etc.) og sender dem som IP-pakker.

Figur 2 viser en typisk installasjon for VoIP og/eller videokonferanse SIP eller H.323. VoIP/konferanseoperatøren opererer typisk en kontrollinfrastruktur (17) med en kontrollserver (30) og alternativt også mediagateways (22) for å gjennomføre audiokommunikasjon over IP-baserte nettverk (11,13,14) til PSTN [Public Switched Telephone Network - offentlig telefonnett] (18). Kommunikasjonen er initiert i en terminal tilkoblet et endepunkt-kontrollsystem (32). Mange terminaler inkluderer endepunkt-kontrollegenskaper inne i terminalen, som sammen utgjør en multimediaterminal, ofte kalt "softphone" dersom den er implementert i en mobiltelefon / datamaskin. Samtalen blir signalert fra terminalen til kontrollserveren (30) ved hjelp av kontrollprotokollen (220) . Kontrollserveren er typisk en SIP eller H.323 proxy, som kommuniserer med mottakeren og etablerer en forbindelse. Terminalene er instruert til å bruke en IP-portadresse-kombinasjon for mediakommunikasjonen. Mediastrømmen (250) tar standard vei gjennom IP-nettet (11,13,14) til mottakerens terminal, og tale- eller videokommunikasjon kan starte. Dersom mottakeren er en terminal i vanlig telefonnett (PSTN), må kontrollserveren (30) omdirigere samtalen til en passende media-gateway (22) og gjennomføre kallet gjennom det vanlige telefonnett.

Traversering av nettverksadresseoversettere og brannmur Nettverksadresseoversettere (Network Address Translation, NAT) oversetter IP-adresser mellom nett. For eksempel, kan interne IP-adresser i et brukernett (13) være avbildet til det offentlige Internett adresserommet. I hver pakke som forlater det lokale nettet (13) må IP-hodet endres ved å erstatte de lokale adressene med de globale. Det er 4 grunntyper av NAT [STUN]: • Full kjegle (Full Cone), som er sjeldent i bruk pga. sikkerhetsproblemer. • Begrenset kjegle (Restricted Cone), der NAT-IP-avbildningen er gyldig kun med utgående trafikk mot destinasjonen. • Port-begrenset kjegle (Port Restricted Cone), som begrenset kjegle, men med IP-adresse og portavbildning. • Symmetrisk, med forskjellig avbildning for forskjellige destinasjonsadresser.

Brannmurer brukes til å sikre lokalnett. De stenger typisk flertallet av nettverksporter og kaster IP-pakker adressert til disse portene.

NAT og brannmurer er i utstrakt bruk. Alle enhetene som brukes i Internett i dag må være i stand til å håndtere dem. Det er flere praktiske løsninger til å løse NAT- og brannmurproblematikken, bl.a.: • "Universal Plug and Play" (sikkerhetsproblemer med klientkontroll av brannmuråpninger, fungerer ikke med flere NAT nivåer) • STUN [STUN], som er et klient-server-system der serveren svarer på klientens forespørsler med å legge ved klientens observerte globale adresse i svarpakken • TURN-server [TURN] som er en STUN-server med tilleggs-funksjonalitet for å videresende datapakker til en gitt

global IP-mottaker

Gateway på applikasjonsnivå (ITU-standard H.460.17/18/19) til bruk med H.323 standarden

Legg merke til at den foreliggende oppfinnelsen ikke angir noen bestemt av NAT- eller brannvegg-traversalløsningene, og er ment å fungere med alt ovenfor.

Beskrivelse av oppfinnelsen

Grunnprinsippet til denne oppfinnelsen er å omdirigere forsinkelses- eller båndbreddefølsom trafikk til et dedikert nettverk (15) i den hensikt å yte visse tjenestekvalitetsgarantier til brukeren av nettverkstjenesten. Dette dedikerte nettet er et transportnett bestående av videresendingsanordninger (20) i flere tilstedeværelsesspunkter (Points of Presence, PoP) , internt sammenkoblet med kanaler med garantert båndbredde, eid eller leid av transportnett-leverandører (12). Nettverket er koblet sammen med flere Internett-tjenesteleverandører (10).

Trafikken omdirigeres til dette dedikerte transportnettet (15) ved å bruke en applikasjonsspesifikk selektiv omdirigeringsenhet (31) . Denne enheten omdirigerer utvalgt trafikk som skal til en vilkårlig adresse til adressen til en videresendingsanordning (20) i transportnettet. Trafikken kan velges ut ved å analysere pakkehodet (130) eller pakkeinnhold (150) , eller ved å samhandle med en sentralisert eller distribuert server (30). For å omdirigere pakkene til videresendingsanordningen, kan denne applikasjonsspesifikke selektive omdirigeringsenheten bruke mange mekanismer, inklusivt IP-tuneller og proxy-mekanismer på transportlaget.

Pakkene utvalgt for omdirigering til det dedikerte transportnettet (15) er adressert (102) til en videresendingsanordning (20) innenfor det dedikerte nettet (15). Adressen til denne videresendingsanordningen (20) er bestemt fra en avbildning mellom et adresserom og adressene til videresendingsanordningene innenfor transportnettet. Dette adresserommet kan være IP-adresserom, eller PSTN E.164 -adresserom, eller et annet adresserom som inneholder nettverksadressene til avsender og mottaker. Denne videresendingsanordningen (20) kan være en IP-ruter, eller et transportrelay (33) som opererer som en SIP eller H.323 media-proxy.

Denne avbildningen kan implementeres på forskjellige måter. Den kan baseres på BGP ruteinformasjon samlet i transportnettet fra tilkoblede ISP-er. Den kan baseres på målinger av for eksempel nåværende trafikkbelastningen i transportnettet. Den kan baseres på nettverkmessig avstand, for eksempel hvilken videresendingsanordning som er nærmest destinasjonsadressen, eller hvilken videresendingsanordning som er nærmest kildeadressen.

Utførelsesform 1

Den første utførelsesformen omfatter et dedikert transportnett (15), en applikasjonsspesifikk omdirigeringsenhet (31), og tilhørende videresendingsanordninger (20), som vist i figur 3.

Det dedikerte transportnettet (15) omfatter tilstedeværelses-punkter (PoP) som er lokalisert i nærheten av de lokale Internett-tjenesteleverandørene (10). PoP-ene er sammenkoblet med fysiske eller virtuelle linker (50) med garantert båndbredde.

Denne utførelsesformen er avhengig av en applikasjonsspesifikk omdirigeringsenhet (31) som velger relevant trafikk fra lokalnettet (13) og videresender denne trafikken til det dedikerte transportnettet (15) via standard ISP brukt av kunden (10). Videresendingen kan gjøres ved bruk av IP-tunellering eller en proxy-operasjon som bruker SIP eller H.323. Videresendingsanordningen (20) kan implementeres som IP-rutere eller SIP/H.323 media-proxier.

I dette oppsettet, vil all urelatert trafikk, slik som e-post og filoverføring følge den vanlige IP-ruten (11), mens forsinkelse- og båndbreddsensitiv trafikk omdirigeres til et dedikert transportnett (15), med tilstrekkelig kapasitet, som vist i figur 4.

Omdirigeringen kan brukes også på signaleringstrafikk, men signaleringen kan også bruke vanlige IP-ruter siden den ikke er forsinkelses- og båndbreddesensitiv.

Valgfrie kontrollservere (30) kan kommunisere med applikasjonsspesifikke omdirigeringsenheter for å bidra til å bestemme rutevalget. I tillegg, kan de brukes til tilgangs-kontroll, AAA og katalogtjenester. I tillegg kan hvert lokalnett ha flere endepunkter som vist i figur 5. Flere endepunkter kan betjenes av en konsentrator typisk lokalisert i bedriftens DMZ.

Arkitekturen støtter multikasting. Flerpartskonferanser kan arrangeres med unikast-multikast reflektorer [REFLECT] iverksatt i (20) og egen-multikast iverksatt i (15).

Utførelsesform 2

I denne utførelsesformen vist i figur 6, er kontrollserveren (30) lokalisert i det offentlige IP-nettet, typisk i nærheten av det dedikerte transportnettet. En eller flere transport-relayer (33) er plassert sentralt i det dedikerte transportnettet og kan betjene mange brukere.

I denne utførelsesformen må SIP/H.323 endepunktkontrollsystemet (32) i terminalene (1) konfigureres til alltid å kontakte kontrollserveren (30) som utgående signalerings-proxy. Signaleringsstien er indikert mellom terminalene og proxyen (220) . Kontrollserveren vedlikeholder en avbildning i transportrelayen (33) ved bruk av en kontrollprotokoll

(200). Etter initial signalering mellom endepunktkontrollsystemet (32) og kontrollserveren (30), er terminalen instruert til å sende mediastrømmen (250) over det dedikerte transportnettet (15) ved å bruke transportrelay (33) som utgående mediaproxy. Kontrollserveren omskriver kilde- og destinasjons- IP-adresser/porter som en del av mediaomdirigeringen, for å sikre at en pakke som er omdirigert til mediaproxyen vil bli videresendt til den opprinnelige destinasjonen.

Utførelsesform 3

Utførelsesform 3 ligner som vist i figur 7 på utførelsesform 2, med den forskjell at kontrollserveren (30) ikke kontrollerer transportrelay (33) direkte. I stedet benyttes det en modifisert "Interactive Connectivity Establishment"

[ICE] -prosedyre, som brukes til å instruere transportrelay (33) hvor pakkene skal sendes.

I denne utførelsesformen svarer funksjonaliteten til transportrelay (33) til en TURN-server [TURN]. Avsenders endepunktkontrollsystem (32) er konfigurert til å bruke transportrelay (33) som utgående media-proxy. Dermed dirigeres media til det dedikerte nettverket. Den modifiserte "Interactive Connectivity Establishment" [ICE] -prosedyren brukes til å unngå å sende data mellom endepunkter som står ved siden av hverandre via det dedikerte transportnettet (15). Denne prosedyren inkluderer to trinn: a) Avsenderendepunktet verifiserer hvorvidt endepunktet som skal motta data har en IP-adresse i det samme nettverksegment og at dette endepunktet kan nås. Dersom dette stemmer, vil det dedikerte nettet (15) ikke bli brukt.

b) Ellers vil transport relay (33) bli brukt.

Når transport-relay (33) benyttes for å overføre data over et

dedikert nettverk (15), løses NAT traversering implisitt ved bruk av TURN.

Utførelsesform 4

I denne utførelsesformen velger den applikasjonsspesifikke selektive omdirigeringsenheten (31) pakkene som skal sendes videre over det dedikerte transportnettet (15) ved pakke-inspeksjon som vist i figur 8.

Pakkeselektoren (60) velger hvilke pakker som skal videresendes til det dedikerte transportnettverket (15) ved å analysere de innkommende pakkene. Figur 8 viser hvordan pakkene som stemmer med en gitt header-felt-spesifikasjon

(120) sendes over (15). Alle andre pakker sendes via standard Internett-sti (11).

Pakker som sendes over (15) er innpakket til en gitt adresse

(102) i det dedikerte nettverket (15). Der blir pakkene pakket ut og videresendt til sin destinasjon (101).

Den applikasjonsspesifikke selektive omdirigeringsenheten (31) lærer avbildning mellom global adresse (101) og den lokale adressen (102) fra kontrollservere (30) ved å benytte en "forespørsel-respons" -protokoll (200). Omdirigeringsenheten (31) kan spørre om hvilken adresse i det dedikerte transportnettverket (15) som skal brukes for å sende data til destinasjonen (101) ved å bruke melding (210). Svaret blir

levert i meldingen (211).

Alternativt kan avbildningen gjøres i endepunktkontrollsystemet (32) som vist i figur 9.

Ref& ranser

[CABO] Nick Fefamster, Lixin Gao and Jennifer Rexford: "How to lease Internet in your spare time", ACM SIGCOMM Computer Communications Review journal, pages 61-64, Jan. 2007.

[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", IETF draft-ietf-mmusic-ice-16 (work in progress), June 2007.

[REFLECT] Tarik Cicic, Haakon Bryhni, Steinar Sørlie: "Multicast-Unicast Reflector", In proceedings of Protocols for Multimedia Communications (PROMS) conference, pages 60-69, Krakow, Poland, 2000.

[RFC1633] R. Braden, D. Clark, S. Shenker: "Integrated Services in the Internet Architecture: an Overview", IETF, June 1994.

[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss "An Architecture for Differentiated Services", IETF, Dec. 1998.

[RFC4364] E. Rosen and Y. Rekhter: "BGP/MPLS IP Virtual Private Networks (VPNs)", IETF, Feb. 2006.

[STUN] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.

[TURN] J. Rosenborg, R. Mahy, C. Huitema: "Traversal Using Relays around NAT (TURN): Relay Extensions to Session

Traversal Utilities for NAT (STUN)", IETF draft-ietf-behave-turn-06 (work in progress), 2007.

Claims (15)

1. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem, omfattende av lokale nettverk (13), et transportnett (15), med videresendingsanordning (20) ved multiple installasjoner, internt sammenkoblet ved kommunikasjonskanaler med garantert kapasitet, koblet til multiple Internet tjenesteleverandører (ISPer), karakterisert ved at nevnte transportnett med garantert kapasitet dedikert til godkjente brukere, og hvor adgangskontroll til transportnettet utføres av kontrollservere (30), og en applikasjonsspesifikk, selektiv omdirigeringsenhet (31) omdirigerer (videresender) utvalgt trafikk som er sensitiv for forsinkelse og overføringskapasitet, adressert til en destinasjonsadresse til adressen til en videresendingsanordning (20) i transportnettet, der adressen til nevnte videresendingsanordning er bestemt ved en avbildning mellom et adresserom og adressene til videresendingsanordningene i transportnettet.

2. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge krav 1, der minst ett lokalt nettverk (13) omfatter nevnte applikasjonsspesifikke, selektive omdirigeringsenhet (31).

3. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge krav 1, der nevnte applikasjonsspesifikke, selektive omdirigeringsenhet (31) er lokalisert i en terminal (1) med et endepunkt kontroll system (32) .

4. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der nevnte applikasjonsspesifikke, selektive omdirigeringsenhet (31), omdirigerer utvalgt trafikk til en destinasjonsadresse til adressen til en videresendingsanordning (20) i transportnettet, der adressen til nevnte videresendingsanordning er bestemt av en avbildning mellom informasjon i pakkehodet (130) eller innholdet i pakken (150) og adressen til videresendingsanordningen i transportnettet.

5. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der nevnte avbildning er kontrollert av en sentralisert eller distribuert kontrollserver (30), som implementerer en avbildningsfunksjon mellom et adresserom og adressene til videresendingsanordning (20) i transportnettet (15).

6. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der adressen til videresendingsanordningen (20) er en IP-adresse.

7. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der avbildningen er basert på BGP-ruting-informasjon fra transportnettet.

8. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der avbildningen er basert på den aktuelle nettverksbelastningen i transportnettet.

9. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der den valgte videresendingsenhet i transportnettet som velges i avbildningsfunksjonen, er den videresendingsanordning som er nærmest destinasjonsadressen.

10. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der den valgte videresendingsanordning i transportnettet som er valgt i avbildningsfunksjonen, er den videresendingsanordningen som er nærmest kildeadressen.

11. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der kontrollserveren administrerer rutingskonfigurasjon i transportnettet.

12. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der kommunikasjonen mellom kontrollserveren og den applikasjonsspesifikke, selektive omdirigeringsenheten er kryptert.

13. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der omdirigeringsenheten bruker tunneler til å omdirigere pakker til videresendingsanordningen.

14. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der omdirigeringsenheten bruker en proxy-mekanisme til å omdirigere pakker til videresendingsanordningen.

15. Ende-til-ende applikasjonsspesifikt, selektivt transportsystem i følge et av de foregående krav, der kontrollsystemet (32) bruker TURN til å omdirigere pakker til videresendingsanordningen.