NO325719B1 - Dataoverforingssystem, samt tilhorende fremgangsmate - Google Patents

Dataoverforingssystem, samt tilhorende fremgangsmate Download PDF

Info

Publication number
NO325719B1
NO325719B1 NO20012744A NO20012744A NO325719B1 NO 325719 B1 NO325719 B1 NO 325719B1 NO 20012744 A NO20012744 A NO 20012744A NO 20012744 A NO20012744 A NO 20012744A NO 325719 B1 NO325719 B1 NO 325719B1
Authority
NO
Norway
Prior art keywords
lsr
rsvp
user equipment
message
accordance
Prior art date
Application number
NO20012744A
Other languages
English (en)
Other versions
NO20012744D0 (no
NO20012744L (no
Inventor
Nail Kavak
Original Assignee
Teliasonera Ab Publ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Teliasonera Ab Publ filed Critical Teliasonera Ab Publ
Publication of NO20012744D0 publication Critical patent/NO20012744D0/no
Publication of NO20012744L publication Critical patent/NO20012744L/no
Publication of NO325719B1 publication Critical patent/NO325719B1/no

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/825—Involving tunnels, e.g. MPLS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/4608—LAN interconnection over ATM networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
    • H04L47/746—Reaction triggered by a failure
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • H04L47/786—Mapping reservation between domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/826—Involving periods of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
    • H04Q11/0478—Provisions for broadband connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5614—User Network Interface
    • H04L2012/5618—Bridges, gateways [GW] or interworking units [IWU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5619—Network Node Interface, e.g. tandem connections, transit switching
    • H04L2012/562—Routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5629—Admission control
    • H04L2012/563—Signalling, e.g. protocols, reference model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5638—Services, e.g. multimedia, GOS, QOS

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Measurement And Recording Of Electrical Phenomena And Electrical Characteristics Of The Living Body (AREA)
  • Medicines Containing Material From Animals Or Micro-Organisms (AREA)
  • Diaphragms For Electromechanical Transducers (AREA)
  • Cable Transmission Systems, Equalization Of Radio And Reduction Of Echo (AREA)

Description

Den foreliggende oppfinnelse vedrører et dataover-føringssystem omfattende et hovednettverk, flere rutere, og flere sluttbrukerutstyr, hvor systemet er tilpasset til å etablere end-to-end dataoverføringsbaner over hovednettverket, nevnte sluttbruker-utstyrer er tilpasset til å anvende RSVP (Resource Reservation Protocol)-meldinger for å overføre deres spesifikke krav og ved at systemet er tilpasset til å anvende MPLS (Multi Protocol Labell Swapping) for å motta nevnte RSVP-meldinger og å etablere merkesvitsjebaner (LSPs) over nevnte hovednettverket, basert på innholdet av nevnte RSVP-meldinger. Oppfinnelsen vedrører videre en fremgangsmåte for å etablere end-to-end dataoverføringsbaner i et dataoverføringssystem omfattende et hovednettverk, flere rutere, og flere slutt-bruker-utstyrer, hvor nevnte sluttbrukerutstyrer anvender RSVP (Resource Reservation Protocol)-meldinger for å overføre deres spesifikke krav og ved at nevnte systemet anvender MPLS (Mulit Protocol Labell Swapping) for å motta nevnte RSVP-meldingene og å etablere merkesvitsjede baner (LSPs) over hovednettverket, basert på innholdet av RSVP-meldingene .
RSVP er blitt spesifisert av Internet Engineering Task Force (IETF). Den spesifiserer mekanisme for allokering av ressurser i forbindelsesløse internett. Hvis RSVP skal fungere optimalt må de underliggende nettverkene også frembringe, ved siden av «beste modus», ulike tjenesteklasser (f.eks. ATM). RSVP kan anvendes over ATM som et middel for å frembringe sikker tjeneste til applikasjonsbrukere. I dette tilfellet anvender RSVP ressurser på et pakke/appli-kasjonsnivå som siden blir omformet, eller rutet, for å garanteres på ATM-nivå. Det eksisterer i ATM bestemte løsninger som beskriver hvordan ruting av RSVP over ATM kan oppnås. Alle disse løsningene anvender det klassiske opplegget for IP over ATM (dvs. Hop-by-hop).
Det antas i hovedsak at RSVP har skaléringsproblemer i nettverk over store områder pga. minneforbruket og kraft-krevende prosesseringskrav. Nåværende er RSVP den eneste mekanismen hvorigjennom applikasjoner kan sende deres QoS (tjenestekvalitet) krav.
MPLS (multiprotokoll merkeveksling) er ment å anvendes i ryggradsnettverk og skalérer bedre enn RSVP. Imidlertid er ikke MPLS tilgjengelig for terminal-forbindelser som ikke er end-to-end. Mekanismene er heller ikke istand til å frembringe en brukers krav til MPLS.
Viswanathan et al. ("Soft state switching, a proposal to extend RSVP for switching RSVP flows", August 1997, Internet draft) omtaler en fremgangsmåte for å etablere en svitsjet bane med garantert QoS for RSVP flyt i en MPLS omgivelse. I Davie et al. ("Use of labell switching with RSVP", March 1998, Internet draft) beskrives det bruken av merkesvitsjing med RSVP. I Swallow et al. ("Extensions to RSVP for LSP tunnels", November 1998, Internet draft) vises det bruk av RSVP og de nødvendige utvidelsene som må til for å etablere merkesvitsjflytt (LSPs) i MPLS. Davie et al.
("Use of labell switching with RSVP", July 1998, Internet draft) gir en beskrivelse hvordan ATM svitsjer kan brukes
som merkesvitsje ruter i MPLS arkitektur. I patentskriften GB 2320159 A omtales det en samlet Internettrutersvitsjing, og i EP 0790751 A2 beskrives det styringen av ATM virtuelle krets med protokoller for å reservere resurser.
I et dataoverføringssystem, ifølge foreliggende oppfinnelse, overføres sluttbrukere deres QoS-krav via RSVP til MPLS som samler de relativt små individuelle RSVP-strømmene til større strømninger i én, eller et antall, datastrømmer. Fordelene som oppnås fra dette er at der ikke er noe behov for at et offentlig nettverk skal huske små strømmer og at slike nettverk har flere detaljer, eller mer eksakt informasjon, vedrørende en brukers QoS-krav. Effekten er at kravene på overførings-kapasitet og nett-verksressurser, f.eks. prosessor og minne, blir redusert. RSVP kontrollpakker blir sendt via et MPLS-nettverk for å gjøre nettverket transparent til RSVP. Terminaler anvender RSVP for å overføre deres krav vedrørende ressurser til nettverket. Aksessnoder har MPLS funksjonalitet som tillater dem å samle datastrømmene. I tillegg blir mange små datastrømmer overført over kun én forbindelse hvis de har de samme QoS-karakteristikkene.
Ifølge et første aspekt ved foreliggende oppfinnelse er det frembrakt et dataoverføringssystem omfattende et hovednettverk, flere rutere, og flere sluttbrukerutstyr, hvor systemet er tilpasset til å etablere end-to-end dataoverføringsbaner over hovednettverket, nevnte sluttbruker-utstyr er tilpasset til å anvende RSVP (Resource Reservation Protocol)-meldinger for å overføre deres spesifikke krav og ved at systemet er tilpasset til å anvende MPLS (Multi Protocol Labell Swapping) for å motta nevnte RSVP-meldinger og å etablere merkesvitsjebaner (LSPs) over nevnte hovednettverket, basert på innholdet av nevnte RSVP-meldinger, som er kjennetegnet ved at
- et første sluttbrukerutstyr (TEI) som krever forbindelse til et andre sluttbrukerutstyr (TE2) er ordnet til å søke en RSVP-PATH-melding som indikerer en krevd QoS, til en inngående LSR (Labell Switch Routers) til nevnte hovednettverket, via et første sluttbrukernettverk hvortil nevnte første sluttbrukerutstyret (TEI) er forbundet, - nevnte inngående LSR er anordnet for å innkapsle RSVP-PATH meldingen og å sende den gjennom hovednettverket til en utgående LSR til nevnte hovednettverket, - nevnte utgående LSR, ved mottak av nevnte RSVP-PATH meldingen, er anordnet for å dekapsle meldingen og utstede en PATH-melding mot et andre sluttbrukernettverk hvortil nevnte andre sluttbrukerutstyret (TE2) er tilhørende, - nevnte andre sluttbrukerutstyr (TE2) er ved mottak av forbindelsen til nevnte første sluttbrukerutstyret (TEI)anordnet for å sende en RESV-melding til nevnte første sluttbrukerutstyret (TEI), - nevnte utgående LSR, ved mottak av RESV-meldingen, er anordnet til:
- midlertidig lagre RESV-meldingen, og
- etablere en merkesvitsjingsbane (LSP) til nevnte inngående ruter, basert på parametrene som rommes i RESV-meldingen, - nevnte utgående LSR, ved etablering av den LSP, er anordnet til å innkapsle den midlertidige lagrede RESV-meldingen og sende den via den etablerte LSP til den nevnte inngående LSR, - nevnte inngående LSR, ved mottak av nevnte RESV-meldingen, er anordnet til å dekapsle RESV-meldingen og sende den mot første sluttbrukerutstyret (TEI), for derved å etablere en én-veisrettet forbindelse fra det første sluttbrukerutstyret (TEI) til det andre sluttbrukerutstyret (TE2).
Systemet kan være tilpasset til å frembringe end-to-end tjenestekvalitet (QoS) gjennom samvirke mellom RSVP og
MPLS.
Systemet kan være tilpasset til å samle et antall RSVP-meldinger, som har den samme QoS-semantikk, til en enkel LSP.
I det minste noen av sluttbrukernettverkene kan være lokalnettverk (LANs).
Hovednettverket kan være et ATM-nettverk, tilpasset for overføring av IP-datapakker og som omfatter et antall samkoblede ATM-svitsjer, ved at minst to av nevnte ruterne er randrutere for ATM-nettverket, og ved at randruterne er merkesvitsjede rutere (LSRs), tilpasset til å være koblet til sluttbrukerutstyr for etablering av énveisrettet forbindelser mellom sluttbrukerutstyr.
En utgående LSR kan være tilpasset til å velge en reservasjonsstil for en RSVP-sesjon fra et sett av mulige reservasjonsstiler, en RSVP-sesjon blir identifisert av en unik tuppel, og ved at en RSVP-sesjon er tilpasset til å frembringe én, eller flere, LSPs, avhengig av den valgte reservasjonsstilen.
Settet av reservasjonsstiler kan omfatte, inter alia, faste filtre (FF), tilfeldige filtre (WF) og felles eksplisitt (SE).
LSPs kan settes opp av utgående LSRs, og ved at en første åpen kortbane (OSPF) ruteinfrastruktur til nevnte systemet er tilpasset til å indikere nevnte LSRs.
De utgående LSR kan frembringes enten av grenseområderutere (ABRs), eller autonome grensesystemrutere (ASBRs), eller rand-LSRs med tilkoblede undernett, og ved at nevnte LSRs er tilpasset til å støtte ulike typer rutere som definerer sendeekvivalente klasser (FEC) elementer.
ABR-nodene kan være tilpasset til å generere FECs som inneholder adresse-prefikser for i det minste interområderutere, eller intraområderutere, og ved at rand-LSR noder er tilpasset til å generere FECs og deres tilkoblede undernett .
Rand-LSR nodene kan være tilpasset til å definere én FEC for alle adresseprefiksene til deres tilkoblede undernett .
De utgående LSR kan være tilpasset til å anvende merkeruting (LM) for å distribuere FEC-merker til oppstrømsnaboer.
Ifølge et andre aspekt ved foreliggende oppfinnelse er det frembrakt en fremgangsmåte for å etablere end-to-end dataoverføringsbaner i et dataoverføringssystem omfattende et hovednettverk, flere rutere, og flere slutt-bruker-utstyr, hvor nevnte sluttbrukerutstyr anvender RSVP (Resource Reservation Protocol)-meldinger for å overføre deres spesifikke krav og ved at nevnte systemet anvender MPLS (Mulit Protocol Labell Swapping) for å motta nevnte RSVP-meldingene og å etablere merkesvitsjede baner (LSPs) over hovednettverket, basert på innholdet av RSVP-meldingene, hvor fremgangsmåten er kjennetegnet ved
- et første sluttbruker-utstyr (TEI) krever forbindelse til et andre sluttbrukerutstyr (TE2) som
utsteder en RSVP-PATH melding, som indikerer en krevt QoS, til en inngåe-nde LSR (Labell Switch Router) til nevnte hovednettverket, via et første sluttbrukernettverk hvortil sluttbrukerutstyret (TEI) er tilhørende, - nevnte inngående LSR innkapsler nevnte RSVP-PATH meldingen og sender den gjennom nevnte hovednettverket til en utgående LSR til nevnte hovednettverket, - nevnte utgående LSR, ved mottak av nevnte RSVP-PATH meldingen, dekapsler meldingen og utsteder en PATH-melding mot et andre sluttbrukernettverk hvortil nevnte andre sluttbrukerutstyret (TE2) er tilhørende, - nevnte andre sluttbrukerutstyr (TE2) sender ved mottak av forbindelsen til nevnte første sluttbrukerutstyret (TEI) en RESV-melding mot nevnte første sluttbrukerutstyret(Tel),
- nevnte utgående LSR, ved mottak av RESV-meldingen,
- lagrer midlertidig RESV-meldingen, og
- etablerer en merkesvitsjet bane (LSP)til den nevnte inngående ruteren, basert på parametrene som rommes i RESV-meldingen, - nevnte utgående LSR, ved etablering av den LSP, innkapsler den midlertidige lagrede RESV-meldingen og sender den via den etablerte LSP til den nevnte inngående LSR, - nevnte inngående LSR, ved mottak av nevnte RESV-meldingen, dekapsler RESV-meldingen og sender den mot første sluttbrukerutstyret (TEI), for derved å etablere en énveisrettet forbindelse fra det første sluttbrukerutstyret (TEI) til det andre sluttbrukerutstyret (TE2).
Fremgangsmåten kan være kjennetegnet ved at nevnte systemet frembringer end-to-end tjenestekvalitet (QoS) gjennom samvirke mellom RSVP og MPLS.
Fremgangsmåten kan være kjennetegnet ved at nevnte systemet samler et antall RSVP-meldinger, som har de samme QoS-semantikkene, til en enkelt LSP.
Fremgangsmåten kan være kjennetegnet ved at en utgående LSR til nevnte hovednettverket velger en reservasjonsstil for en RSVP-sesjon fra et sett av mulige reservasjonsstiler, en RSVP-sesjon blir identifisert ved en unik tuppel, og ved at RSVP-sesjonen frembringer én, eller flere, LSPs, avhengig av den valgte reservasjonsstil.
Fremgangsmåten kan være kjennetegnet ved at nevnte sett av reservasjonsstiler omfatter, inter alia, faste filtre (FF), tilfeldige filtre (WF) og felles eksplisitt
(SE) .
Fremgangsmåten kan karakteriseres ved at utgående LSRs, setter opp LSPs, og ved en første åpen kortbane (OSPF) ruteinfrastruktur til nevnte systemet indikerer disse nodene.
Fremgangsmåten kan karakteriseres ved at nevnte utgående LSRs blir frembrakt enten ved grenseområderutere (ABRs) eller autonome grensesystemrutere (ASBRs), eller rand-LSRs med tilkobledeundernett, og ved at nevnte LSRs støtter ulike typer rutere som definerer sendeekvivalente klasser (FEC) elementer.
Fremgangsmåten kan videre karakteriseres ved at nevnte ABR-nodene genererer FECs som inneholder adresseprefikser for minst interområderutere, eller intraområderutere, og ved at nevnte rand-LSR noder genererer FEC for deres tilkoblede undernett.
Fremgangsmåten kan være kjennetegnet ved at nevnte rand-LSR nodene definerer én FEC for alle adresseprefiksene til deres tilkoblede undernett.
Fremgangsmåten kan videres kjennetegnes ved at nevnte utgående LSRs anvender merkeruting (LM) for å distribuere FEC-merker til oppstrømsnaboer.
Fremgangsmåten kan karakteriseres ved at hver LSR på banen mot en inngående LSR, ved mottak av en LM-melding: - sjekker om, eller ikke, en støtteenhet ifølge rutingen er det neste hoppet for en FEC,og enten: - trekker tilbake et nedstrømsmerke, i tilfellet at det ikke er det neste hoppet,
ved å reagere med en merketilbaketrekkings-
melding (LW), eller
- sjekker om dens ruter-id er i LSR-vektoren, i tilfellet det er det neste hoppet.
Fremgangsmåten kan karakteriseres ved at hver av nevnte LSRs: - vraker merkerutingen, i tilfellet at ruter-id'en er i nevnte vektoren, og sender en NAK til støtte-enheten, eller - i tilfellet at ruter-id ikke er i nevnte vektoren,
- finner et oppstrømsmerke for den FEC,
- kryssforbinder det med nedstrømsmerket, og - sender en merkeruting (LM) melding for opp-strømsmerket til alle oppstrømsnaboer, nevnte LM-melding har LSR"s ruter-id lagt til LSR-banevektorlisten, og Hop-telleren er satt til en verdi på den mottatte LM-meldingen pluss 1.
Fremgangsmåten kan karakteriseres ved at nevnte inngående LSR, ved mottak av LMs: - beholder kun merkene som anvendes for forsendelse, og - undersøker en LSR-banevektorliste for å sjekke om en sløyfe er blitt etablert.
Fremgangsmåten kan være kjennetegnet ved at nevnte inngående LSRs, ved mottak av en IP-datapakke: - modifiserer TTL-verdien basert på Hop-tellerverdien forbundet med en FEC, - legger til en mellomliggende heading til IP-datapakken, og - sender den på en virtuell kanal (VC) forbundet med den FEC. Fremgangsmåten kan karakteriseres ved at nevnte mellomliggende heading - har et merke med verdi 0, som indikerer at forsendelse av IP-datapakken er basert på en IPv4-heading, - og bærer en TTL-verdi lik til en modifisert TTL til nevnte IP-headingen, og ved at en CoS (tjenesteklasse) verdi blir satt til best ytelse.
Fremgangsmåten kan videre karakteriseres ved at nevnte utgående LSRs, ved mottak av merkede IP-datapakker, fjerner den mellom-liggende headingen og leverer IP-datapakken til et IP-lag for videre forsendelse.
Fremgangsmåten kan også karakteriseres ved å periodisk oppfriske nevnte RSVP, PATH og RESV-melding.
Det forannevnte og andre trekk ved foreliggende oppfinnelse skal bedre forstås fra den følgende beskrivelse med henvisning til de vedlagte tegninger, hvori: Fig.l viser skjematisk samvirket mellom RSVP og MPLS, ifølge foreliggende oppfinnelse; og Fig.2 viser skjematisk utgåendebasert LSP-initialisering som anvendes av et dataoverføringssystem ifølge foreliggende oppfinnelse.
En ordliste over forkortelsene som anvendes i denne patentbeskrivelsen er frembrakt nedenfor for å lette forståelsen av foreliggende oppfinnelse.
ABR: Area Border Router
ASBR: Autonomous System Border Router
ATM: Asynchronous Transfer Mode
BGP4: Border Gateway Protocol Version 4
CoS: Class of Service
FEC: Forwarding Information Base
FIB: Forwarding Information Base
FF: Fixed Filter
IETF: Internet Engineering Task Force
IP: Internet Protocol
Ipv4: Internet Protocol Version 4
LDP: Label Distribution Protocol
LIB: Label Information Base
LM: Label Mapping
LR: Label Request
LSP: Label Switched Path
LSR: Label Switched Router
LW: Label Withdraw
NAK: Negative Acknowledgement
OSPF: Open Short Path First
QoS: Quality of Service
RSVP: Resource Reservation Protocol
SE: Shared Explicit
TE: Terminal Equipment
TTL: Time to Live
TLV: Type Length Value
UBR: Unspecified Bit Rate(ATM)
VC: Virtual Circuit
WF: Wildcard Filter
Det skal ses fra den etterfølgende beskrivelsen at foreliggende oppfinnelse frembringer en systemstruktur og protokoll som muliggjør sluttbrukere og overfører deres spesifikke end-to-end QoS-krav ved tilkobling av RSVP-øyer' gjennom en MPLS-samling. Sluttbrukerne formidler deres krav gjennom anvendelse av RSVP-meldinger. MPLS mottar RSVP-meldingene og etablerer merkevekslingsbaner (LSP) over et ryggradsnettverk (f.eks. ATM-nettverk) basert på informasjonen indikert i RSVP-meldingene. MPLS samler også RSVP-strømmer (avhengig av reservasjonsmåte) slik at antallet strømningstilstander blir vesentlig redusert. I tilfellet med overførte QoS-krav, gir dette en økning til end-to-end QoS og nettverk som skalérer mye bedre enn kun et RSVP-nettverk. Anvendelse av MPLS letter RSVP-skaléringsproblemene, omtalt ovenfor, siden individuelle RSVP-strømmer er samlet i et ryggradsnettverk, så som et ATM-nettverk, og svitsjet ved lag 2 i stedet for å bli prosessert ved lag 3 ved hop-by-hop. Hovedfordelen med lag 2-svitsjing er at den øker ytelsen i motsetning til konvensjonelle rutere. Videre er MPLS LSP etablert basert på virkelige sluttbrukerkrav i stedet for en kunstig klassifiseringsprosedyre ved randruterne som foreslått i dag.
Fig.l av de vedlagte tegningene viser skjematisk måten hvori samvirket utføres mellom RSVP og MPLS. Som illustrert i fig.l er sluttbrukerutstyret TEI og TE2 respektivt forbundet til separate nettverk, f.eks. lokalnettverk (LAN), som danner RSVP-øyene som omtalt ovenfor. I praksis vil et antall TE være tilkoblet hvert LAN. MPLS-samlingen kan f.eks. være frembrakt av et ryggradsnettverk omfattende et antall sammenkoblede svitsjer (f.eks. ATM-svitsjer) koblet til merkevekslings-rutere, så som LSR1 og LSR2, ved randen av ryggradsnett-verket. Terminalutstyret TEI og TE2 er derfor respektivt tilkoblet LSR1 og LSR2 via et LAN og dermed til ryggrads-nettverket.
I MPLS er etablering av en merkesvitsjingsbane (LSP) primært basert på bestemmelses-nettverks-prefikset. Imidlertid er det også en mulighet for å klassifisere datapakker basert på kildeadresse, eller bestemmelses-adresse, eller port-id, eller transportprotokoll, etc, eller hvilken som helst kombinasjon derav. Det antas at klassifikasjon basert på bestemmelsessted nettverks-prefiks er nyttig for samling av best modusstrømmer, mens strømningsspesifikke LSP er nyttig for tidskritiske applikasjoner, eller applikasjoner hvor spesifikke garantier er forespurt. Imidlertid trenger ikke klassifi-sering av datapakker basert på transportlager-informasjon være den beste måten å estimere brukerkrav. Det er fornuftig å anta at sluttbrukere vil anvende RSVP for å over-føre deres spesifikke krav. Det er også fornuftig å anta at MPLS vil spille en viktig rolle i ryggraden. Således at tilkobling av RSVP-øyer gjennom en MPLS-samling, som vist i fig.l av de vedlagte tegningene, blir en nøkkelsak for å muliggjøre end-to-end garantier.
Den overliggende driften av ressursreservasjons-protokoll (RSVP) skal nå beskrives, som et eksempel, med henvisning til fig.l og de vedlagte tegningene. Således at drift av RSVP involverer de følgende prosedyretrinnene: 1. Terminalutstyret TEI utsteder en RSVP-PATH-melding som indikerer QoS-kravene via LAN (RSVP-øy) til den inngående randruteren LSR1. 2. Den inngående randruteren LSR1 innkapsler RSVP-PATH-meldingen og sender den via MPLS-samlingen, dvs. gjennom ryggradsnettverket, til den utgående randruteren LSR2. 3. Den inngående randruteren LSR2 dekapsler RSVP-PATH-meldingen og utsteder PATH-meldingen mot det LAN som danner part av mottagende RSVP-øy. 4. Terminalutstyret TE2, hvis den aksepterer forbindelsen, sender en RESV-melding mot terminalutstyret TEI. 5. Ved mottak av RESV-meldingen lager randruteren LSR2 RESV-meldingen og etablerer en merke-vekslingsbane (LSP) til randruteren LSR1, basert på parametrene som rommes i RESV-meldingen; prosedyren som anvendes for å etablere LSP vil bli forklart i den etterfølgende beskrivelse. 6. Ved etablering av en LSP, innkapsler randruteren LSR2 den tidligere lagrede RESV-meldingen og sender den via den etablerte LSP til randruteren LSR1. 7. Mottak av RESV-meldingen, dekapsler randruteren LSR1 RESV-meldingen og sender den mot terminal-utstyret TEI, via det tilhørende LAN.
Ved slutten av den forannevnte prosedyren vil en énveisforbindelse bli etablert fra terminalutstyret TEI til terminalutstyret TE2.
Hvis terminalutstyret TE2 ønsker å sette opp en forbindelse til terminalutstyret TEI, vil den samme prosedyren som omtalt ovenfor bli utført, men i omvendt retning, dvs. TE2 vil utstede RSVP-PATH meldingen, randruteren LSR2 vil være inngående ruter og randruteren LSR1 vil være utgående ruter.
Måten hvordan samling av RSVP-strømninger til merkevekslingsbaner (LSP) utføres, skal nå beskrives. Siden LSR består av samlingspunkter, kan flere RSVP-strømmer samles i den samme LSP så lenge som de har den samme QoS-semantikk. Imidlertid kan en mottakernode velge blant et sett av mulige reservasjonsmåter for hver sesjon, og hver RSVP-sesjon må ha en bestemt stil. Med andre ord har senderne ingen påvirkning ved valg av reservasjons-stil. Mottakeren kan velge ulike reservasjonsmåter som rutes til ulike LSP.
En RSVP-sesjon identifiseres av en unik (mottaks-adresse, protokoll, mottaksport) tuppel. Således at en RSVP-sesjon kan danne én, eller flere, LSP, avhengig av reservasjonsmåte som velges. Noen reservasjonsmåter, så som faste filtre (FF), tilegner en bestemt reservasjon til en individuell sendernode. Andre reservasjonsmåter, så som tilfeldige filtre (WF) og felles eksplisitt (SE), kan dele en reservasjon blant flere sendernoder.
Den faste filter (FF) måten for reservasjon danner en bestemt reservasjon for trafikk fra hver sender som ikke deles av andre sendere. Denne stilen er felles for applikasjoner hvori trafikk fra hver sender vil være samløpende og uavhengig. Det totale antall reserverte båndbredder på en link for sesjoner som anvender FF-stilen er summen av reservasjoner de individuelle senderne. Pga. at hver sender har sin egen reservasjon, blir et unikt merke og en separat merkesvitsjet bane tildelt hver sender. Dette resulterer i en punkt-til-punkt LSP mellom hvert sender-mottakerpar.
Med tilfeldig filter (WF) måten for reservasjon, anvendes en enkel felles reservasjon for alle senderne. Den totale reservasjonen på en link blir værende den samme uavhengig av antallet sendere. Denne stilen er nyttig i applikasjoner hvori ikke alle senderne sender trafikk på samme tid. En enkelt merkesvitsjingsbane dannes for alle senderne, pga. at alle senderne til sesjonen er dekket av reservasjonen. På linker som senderne deler, er et enkelt merke alokert. Hvis det kun er én sender, ser LSP ut som en normal punkt-til-punkt forbindelse. Når et antall sendere er tilstedeværende blir et multipunkt-til-punkt LSP frembrakt. Dette er fordelen med å minimere antallet LSP som muliggjør bedre skaléring av nettverket.
Med felles eksplisitt (SE)-måte ved reservasjon er
hvilken som helst sender tillatt å dele reservasjonen, SE-stilen tillater mottaker å eksplisitt spesifisere senderne som skal inkluderes. Det er én enkel reservasjon på en link
for alle senderne listet i RSVP-meldingen. Kun opplistede sendere kan slutte seg til reservasjonen. På grunn av at hver sender er eksplisitt listet i RESV-meldingen kan separate merker tildeles hver sender, dermed dannes separate LSP for hver sender. Ulik FF, deler alle SE LSP en enkelt reservasjon. Ulik WF, dannes en separat LSP for hver sender.
Prosedyrene som anvendes for å etablere utgående initierte merkesvitsjingsbaner (LSP) skal nå beskrives. Disse prosedyrene er basert på en kombinasjon av en uavhengig merkedistribusjon og en konservativ merke tilbake-holdingsmodus. Mer bestemt er merkesvitsjingsbaner (LSP) satt opp ved utgående merkesvitsjingsrutere (LSR), f.eks. grenseområderutere (ABR), eller autonome grensesystemrutere (ASBR), eller rand-LSR med tilkoblede undernett. Den første åpne kortbanen (OSPF) ruteinfra-strukturen indikerer disse nodene. De ulike typene ruter som støttes av disse nodene definerer senderekvivalente klasser (FEC) elementer av FEC TLV og således oppnås strømningssamling. F.eks. definerer en ABR en FEC som inneholder adresseprefikser for sammen-drag (interområder), intraområder, eller andre typer rutere. ASBR bygger en FEC for de eksterne ruterne redistribuert av BGP4. Rand-LSR genererer FEC for deres tilkoblede undernett (intraområde-rutere). En FEC kan være definert for alle adressepre-fikser til tilkoblede undernett .
Hver utgående LSR distribuerer merkene for dens FEC til alle av den oppstrømsnaboer gjennom LDP. Meldings-merkeruting (LM) anvendes for dette formålet. Utgåendebasert LSP-initialisering er skjematisk vist, som et eksempel, i fig.2 av de vedlagte tegningene.
Som illustrert i fig.2 sender grenseområderuteren ABR1 til sin nabo, merkesvitsjingsruter LSR1, en merkeruting (LM) for adresseprefikser «n» og «r» definert i én FEC, dvs. merket: X, FEC(n,r). På grunn av sløyfe-deteksjon, er ruter-id til LSR satt i LSR banevektor TLV til meldingen. Til slutt er Hop-teller TLV til meldingen satt til 1, Hop-telleren anvendes av inngående LSR, LSR2 i fig.2, for å beregne TTL (levetid) verdien til IP-datapakkene som kommer inn i MPLS ryggradsnettverket (f.eks. ATM-nettverk).
I praksis vil hver kjerne LSR på banen mot den inngående LSR ved mottak av en merkerutingsmelding, følge prosedyretrinnet omtalt nedenfor.
Trinn 1. Sjekke om utsteder ifølge rutingen er det neste hopp for FEC. Hvis ikke blir nedstrømsmerket trukket tilbake ved å reagere med en merketilbaketrekkingsmelding (LW), se responsen til LSRI til ABR3 i fig.2. Hvis det er det neste hoppet, fortsett til trinn 2.
Trinn 2. Sjekk om dens ruter-id er i LSR-banevektoren, dvs. en sløyfe er blitt etablert. Hvis ja, vrak merkerutingen og sende en NAK til utsteder. Ellers fortsett til trinn 3.
Trinn 3. Finn et oppstrømsmerke for FEC, kryss-til-koble den med nedstrømsmerket, og send en merkerutingsmelding (LM) for oppstrømsmerket til alle oppstrømsnaboer. LM-meldingen vil ha LSR's ruter-id lagt til LSR-banevektorlisten, og opptelleren settes til verdi til den mottatte LM-meldingen pluss 1.
Etableringen av oppstrøms- og nedstrømsmerking for-enkles hvis VC (virtuell krets) fletting støttes av LSR. Ellers må hver LSR forespørre et nedstrømsmerke for hvert oppstrømsmerke. Dette resulterer i en tittel i LP-signalering og statusinformasjon.
Innløps-LSR, ved mottak av merkerutingen (LM), beholder kun merkene som anvendes for forsendelser. Innløps-LSR sjekker om en sløyfe er blitt etablert ved å undersøke LSR-banevektorlisten. Disse merkene og deres FEC, så vel som Hop-tellerverdiene, vil besette LIB og bli standard-baner for best ytelsestrafikk.
Ved mottak av en IP-datapakke, vil en ingress merke-svits jet ruter, dvs. LSR2 i fig.2: - modifisere TTL-verdien basert på Hop-tellerverdien forbundet med FEC; - legge til en mellomliggende heading til IP-datapåkken; og
- sende den på den VC som er forbundet til FEC.
Den mellomliggende headingen bærer merket med verdi 0 (IPv4 eksplisitt nullmerke) som indikerer at merkestakken må åpnes ved utløps-LSR og formidlingen av IP-datapakker må baseres på IPv4-headingen. Den bærer også en TTL-verdi lik til den modifiserte TTL til IP-headingen. CoS (tjenesteklasse) verdien er satt til best ytelse.
Når en merket IP-datapakke mottas av en utgående LSR, blir den mellomliggende headingen fjernet og pakken leveres til IP-lager for videre forsendelse.
Ved ruteendringer, er nedstrømsmerker for påvirket FEC løsgjort hvis de ikke er i bruk for andre FEC-elementer. Nye merker forespørres fra det nye neste hoppet. Til slutt kan det være nødvendig med ny merke-ruting oppstrøms.
Tabellene vist i fig.2 frembringer videre informasjon vedrørende FEC, merker, Hop-teller, adresseprefikser, og neste hopp for merkesvitsjede rutere, LSR1 og LSR2, sammen med VC oppslagstabeller for LSR1.
Hovedfordelen med innløpsbasert løsning er dens økonomiske anvendelse av VC pga. ruting av et antall FEC inn i en LSP, dvs. strømningssamling. Det må imidlertid bemerkes at strømningssamling øker trafikklasten på VC, som kan resultere i lav ytelse hvis hver VC lager kø, pga. rettferdighet, anvendes for UBR. Andre ulemper er protokollkompleksitet. Sløyfer kan oppstå, men systemet er tilpasset til å oppdage og ødelegge dem hjelp av LSR-vektorbanen.
I RSVP, PATH og RESV er meldingene periodisk opp-datert. Støtte for et stort antall sesjoner kan frembringe skaléringsproblemer. Siden minnet og prosesseringskrav øker lineært med en økning av antallet tilstander, er én måte å øke skaléringsproblemet å øke oppdateringstimeren. Imidlertid utføres dette på bekostning av økning på oppdaterings-pauser. Det er imidlertid mulig å øke oppdateringspausene og likevel være istand til å reagere for hurtigere opp-dagelse av tilkoblings-problemer. F.eks., så snart en topologifeil oppstår, informerer hver node tilstøtende feilen alle de påvirkede nodene.

Claims (29)

1. Dataoverføringssystem omfattende et hovednettverk, flere rutere, og flere sluttbrukerutstyr, hvor systemet er tilpasset til å etablere end-to-end dataoverføringsbaner over hovednettverket, nevnte sluttbruker-utstyr er tilpasset til å anvende RSVP (Resource Reservation Protocol)-meldinger for å overføre deres spesifikke krav og ved at systemet er tilpasset til å anvende MPLS (Multi Protocol Labell Swapping) for å motta nevnte RSVP-meldinger og å etablere merkesvitsjebaner (LSPs) over nevnte hovednettverket, basert på innholdet av nevnte RSVP-meldinger, karakterisert ved at - et første sluttbrukerutstyr (TEI) som krever forbindelse til et andre sluttbrukerutstyr (TE2) er ordnet til å søke en RSVP-PATH-melding som indikerer en krevd QoS, til en inngående LSR (Labell Switch Routers) til nevnte hovednettverket, via et første sluttbrukernettverk hvortil nevnte første sluttbrukerutstyret (TEI) er forbundet, - nevnte inngående LSR er anordnet for å innkapsle RSVP-PATH meldingen og å sende den gjennom hovednettverket til en utgående LSR til nevnte hovednettverket, - nevnte utgående LSR, ved mottak av nevnte RSVP-PATH meldingen, er anordnet for å dekapsle meldingen og utstede en PATH-melding mot et andre sluttbrukernettverk hvortil nevnte andre sluttbrukerutstyret (TE2) er tilhørende, - nevnte andre sluttbrukerutstyr (TE2) er ved mottak av forbindelsen til nevnte første sluttbrukerutstyret (TEI) anordnet for å sende en RESV-melding til nevnte første sluttbrukerutstyret (TEI), - nevnte utgående LSR, ved mottak av RESV-meldingen, er anordnet til: - midlertidig lagre RESV-meldingen, og - etablere en merkesvitsjingsbane (LSP) til nevnte inngående ruter, basert på parametrene som rommes i RESV-meldingen, - nevnte utgående LSR, ved etablering av den LSP, er anordnet til å innkapsle den midlertidige lagrede RESV-meldingen og sende den via den etablerte LSP til den nevnte inngående LSR, - nevnte inngående LSR, ved mottak av nevnte RESV-meldingen, er anordnet til å dekapsle RESV-meldingen og sende den mot første sluttbrukerutstyret (TEI), for derved å etablere en én-veisrettet forbindelse fra det første sluttbrukerutstyret (TEI) til det andre sluttbrukerutstyret (TE2).
2. Dataoverføringssystem i samsvar med krav 1, karakterisert ved at nevnte systemet er tilpasset til å frembringe end-to-end tjenestekvalitet (QoS) gjennom samvirke mellom RSVP og MPLS.
3. Dataoverføringssystem i samsvar med krav 2, karakterisert ved at nevnte systemet er tilpasset til å samle et antall RSVP-meldinger, som har den samme QoS-semantikk, til en enkel LSP.
4. Dataoverføringssystem i samsvar med krav 3, karakterisert ved at minst noen av sluttbrukernettverkene er lokalnettverk (LANs).
5. Dataoverføringssystem i samsvar med krav 3 eller 4, karakterisert ved at nevnte hovednettverket er et ATM-nettverk, tilpasset for overføring av IP-datapakker og som omfatter et antall samkoblede ATM-svitsjer, ved at minst to av nevnte ruterne er randrutere for ATM-nettverket, og ved at randruterne er merkesvitsjede rutere (LSRs), tilpasset til å være koblet til sluttbruker-utstyr for etablering av énveisrettet forbindelser mellom sluttbrukerutstyr.
6. Dataoverføringssystem i samsvar med krav 5, karakterisert ved at en utgående LSR er tilpasset til å velge en reservasjonsstil for en RSVP-sesjon fra et sett av mulige reservasjonsstiler, en RSVP-sesjon blir identifisert av en unik tuppel, og ved at en RSVP-sesjon er tilpasset til å frembringe én, eller flere, LSPs, avhengig av den valgte reservasjonsstilen.
7. Dataoverføringssystem i samsvar med krav 6, karakterisert ved at settet av reservasjonsstiler omfatter, inter alia, faste filtre (FF), tilfeldige filtre (WF) og felles eksplisitt (SE).
8. Dataoverføringssystem i samsvar med krav 6 eller 7, karakterisert ved at LSPs settes opp av utgående LSRs, og ved at en første åpen kortbane (OSPF) ruteinfrastruktur til nevnte systemet er tilpasset til å indikere nevnte LSRs.
9. Dataoverføringssystem i samsvar med krav 8, karakterisert ved at nevnte utgående LSR er frembrakt enten av grenseområderutere (ABRs), eller autonome grensesystemrutere (ASBRs), eller rand-LSRs med tilkoblede undernett, og ved at nevnte LSRs er tilpasset til å støtte ulike typer rutere som definerer sendeekvivalente klasser (FEC) elementer.
10. Dataoverføringssystem i samsvar med krav 9, karakterisert ved at ABR-noder er tilpasset til å generere FECs som inneholder adresse-prefikser for i det minste interområderutere, eller intraområderutere, og ved at rand-LSR noder er tilpasset til å generere FECs og deres tilkoblede undernett.
11. Dataoverføringssystem i samsvar med krav 10, karakterisert ved at nevnte rand-LSR nodene er tilpasset til å definere én FEC for alle adresseprefiksene til deres tilkoblede undernett.
12. Dataoverføringssystem i samsvar med et av kravene 6-11, karakterisert ved at utgående LSR er tilpasset til å anvende merkeruting (LM) for å distribuere FEC-merker til oppstrømsnaboer.
13. Fremgangsmåte for å etablere end-to-end dataover-føringsbaner i et dataoverføringssystem omfattende et hovednettverk, flere rutere, og flere sluttbrukerutstyr, hvor nevnte sluttbrukerutstyr anvender RSVP(Resource Reservation Protocol)-meldinger for å overføre deres spesifikke krav og ved at nevnte systemet anvender MPLS (Mulit Protocol Labell Swapping) for å motta nevnte RSVP-meldingene og å etablere merkesvitsjede baner (LSPs) over hovednettverket, basert på innholdet av RSVP-meldingene, karakterisert ved at - et første sluttbrukerutstyr (TEI) krever forbindelse til et andre sluttbrukerutstyr (TE2) som utsteder en RSVP-PATH melding, som indikerer en krevt QoS, til en inngående LSR (Labell Switch Router) til nevnte hovednettverket, via et første sluttbrukernettverk hvortil sluttbrukerutstyret (TEI) er tilhørende, - nevnte inngående LSR innkapsler nevnte RSVP-PATH meldingen og sender den gjennom nevnte hovednettverket til en utgående LSR til nevnte hovednettverket, - nevnte utgående LSR, ved mottak av nevnte RSVP-PATH meldingen, dekapsler meldingen og utsteder en PATH-melding mot et andre sluttbrukernettverk hvortil nevnte andre sluttbrukerutstyret (TE2) er tilhørende, - nevnte andre sluttbrukerutstyr (TE2) sender ved mottak av forbindelsen til nevnte første sluttbrukerutstyret (TEI) en RESV-melding mot nevnte første sluttbrukerutstyret (TEI), - nevnte utgående LSR, ved mottak av RESV-meldingen, - lagrer midlertidig RESV-meldingen, og - etablerer en merkesvitsjet bane (LSP) til den nevnte inngående ruteren, basert på parametrene som rommes i RESV-meldingen, - nevnte utgående LSR, ved etablering av den LSP, innkapsler den midlertidige lagrede RESV-meldingen og sender den via den etablerte LSP til den nevnte inngående LSR, - nevnte inngående LSR, ved mottak av nevnte RESV-meldingen, dekapsler RESV-meldingen og sender den mot første sluttbrukerutstyret (TEI), for derved å etablere en énveisrettet forbindelse fra det første sluttbrukerutstyret (TEI) til det andre sluttbrukerutstyret (TE2).
14. Fremgangsmåte i samsvar med krav 13, karakterisert ved at nevnte systemet frembringer end-to-end tjenestekvalitet (QoS) gjennom samvirke mellom RSVP og MPLS.
15. Fremgangsmåte i samsvar med krav 14, karakterisert ved at nevnte systemet samler et antall RSVP-meldinger, som har de samme QoS-semantikkene, til en enkelt LSP.
16. Fremgangsmåte i samsvar med krav 14 eller 15, karakterisert ved at en utgående LSR til nevnte hovednettverket velger en reservasjonsstil for en RSVP-sesjon fra et sett av mulige reservasjonsstiler, en RSVP-sesjon blir identifisert ved en unik tuppel, og ved at RSVP-sesjonen frembringer én, eller flere, LSPs, avhengig av den valgte reservasjonsstil.
17. Fremgangsmåte i samsvar med krav 16, karakterisert ved at nevnte sett av reservasjonsstiler omfatter, inter alia, faste filtre (FF), tilfeldige filtre (WF) og felles eksplisitt (SE).
18. Fremgangsmåte i samsvar med et av kravene 14-17, karakterisert ved at utgående LSRs, setter opp LSPs, og ved en første åpen kortbane (OSPF) ruteinfrastruktur til nevnte systemet indikerer disse nodene.
19. Fremgangsmåte i samsvar med krav 18, karakterisert ved at nevnte utgående LSRs blir frembrakt enten ved grenseområderutere (ABRs) eller autonome grensesystemrutere (ASBRs), eller rand-LSRs med tilkoblede undernett, og ved at nevnte LSRs støtter ulike typer rutere som definerer sendeekvivalente klasser (FEC) elementer.
20. Fremgangsmåte i samsvar med krav 19, karakterisert ved at nevnte ABR-nodene genererer FECs som inneholder adresseprefikser for minst interområderutere, eller intraområderutere, og ved at nevnte rand-LSR noder genererer FEC for deres tilkoblede undernett.
21. Fremgangsmåte i samsvar med krav 20, karakterisert ved at nevnte rand-LSR nodene definerer én FEC for alle adresseprefiksene til deres tilkoblede undernett.
22. Fremgangsmåte i samsvar med et av kravene 14-21, karakterisert ved at nevnte utgående LSRs anvender merkeruting (LM) for å distribuere FEC-merker til oppstrømsnaboer.
23. Fremgangsmåte i samsvar med krav 22, karakterisert ved at hver LSR på banen mot en inngående LSR, ved mottak av en LM-melding: - sjekker om, eller ikke, en støtteenhet ifølge rutingen er det neste hoppet for en FEC, og enten: - trekker tilbake et nedstrømsmerke, i tilfellet at det ikke er det neste hoppet, ved å reagere med en merketilbaketrekkingsmelding (LW), eller - sjekker om dens ruter-id er i LSR-vektoren, i tilfellet det er det neste hoppet.
24. Fremgangsmåte i samsvar med krav 23, karakterisert ved at hver av nevnte LSRs: - vraker merkerutingen, i tilfellet at ruter-id'en er i nevnte vektoren, og sender en NAK til støtteenheten, eller - i tilfellet at ruter-id ikke er i nevnte vektoren: - finner et oppstrømsmerke for den FEC, - kryssforbinder det med nedstrømsmerket, og - sender en merkeruting (LM) melding for opp-strømsmerket til alle oppstrømsnaboer, nevnte LM-melding har LSR"s ruter-id lagt til LSR-banevektorlisten, og Hop-telleren er satt til en verdi på den mottatte LM-meldingen pluss 1.
25. En fremgangsmåte i samsvar med enten krav 23 eller 24, karakterisert ved at nevnte inngående LSR, ved mottak av LMs: - beholder kun merkene som anvendes for forsendelse, og - undersøker en LSR-banevektorliste for å sjekke om en sløyfe er blitt etablert.
26. Fremgangsmåte i samsvar med et av kravene 23-25, karakterisert ved at nevnte inngående LSRs, ved mottak av en IP-datapakke: - modifiserer TTL-verdien basert på Hop-tellerverdien forbundet med en FEC, - legger til en mellomliggende heading til IP-datapakken, og - sender den på en virtuell kanal (VC) forbundet med den FEC.
27. Fremgangsmåte i samsvar med krav 26, karakterisert ved at nevnte mellomliggende heading - har et merke med verdi 0, som indikerer at forsendelse av IP-datapakken er basert på en IPv4-heading, - og bærer en TTL-verdi lik til en modifisert TTL til nevnte IP-headingen, og ved at en CoS (tjenesteklasse) verdi blir satt til best ytelse.
28. Fremgangsmåte i samsvar med enten krav 26 eller 27, karakterisert ved at nevnte utgående LSRs, ved mottak av merkede IP-datapakker, fjerner den mellomliggende headingen og leverer IP-datapakken til et IP-lag for videre forsendelse.
29. Fremgangsmåte i samsvar med et av kravene 14 til 28, karakterisert ved periodisk å oppfriske nevnte RSVP, PATH og RESV-melding.
NO20012744A 1998-12-15 2001-06-05 Dataoverforingssystem, samt tilhorende fremgangsmate NO325719B1 (no)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SE9804320A SE515465C2 (sv) 1998-12-15 1998-12-15 Förbättringar inom, eller hänförande sig till, dataöverföringssystem
PCT/SE1999/002278 WO2000036871A1 (en) 1998-12-15 1999-12-07 Data transmission system adapted to provide interworking between rsvp and mpls

Publications (3)

Publication Number Publication Date
NO20012744D0 NO20012744D0 (no) 2001-06-05
NO20012744L NO20012744L (no) 2001-08-08
NO325719B1 true NO325719B1 (no) 2008-07-07

Family

ID=20413654

Family Applications (1)

Application Number Title Priority Date Filing Date
NO20012744A NO325719B1 (no) 1998-12-15 2001-06-05 Dataoverforingssystem, samt tilhorende fremgangsmate

Country Status (8)

Country Link
EP (1) EP1142435B1 (no)
AT (1) ATE336874T1 (no)
DE (1) DE69932851D1 (no)
DK (1) DK1142435T3 (no)
EE (1) EE04895B1 (no)
NO (1) NO325719B1 (no)
SE (1) SE515465C2 (no)
WO (1) WO2000036871A1 (no)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6795445B1 (en) * 2000-10-27 2004-09-21 Nortel Networks Limited Hierarchical bandwidth management in multiservice networks
US7099334B2 (en) 2001-03-29 2006-08-29 Nortel Networks Limited ATM over MPLS connection establishment mechanism
GB2375023B (en) * 2001-04-26 2003-07-16 Marconi Comm Ltd Improvements in and relating to telecommunications networks
DE10133473C1 (de) * 2001-07-10 2003-02-20 Siemens Ag Verfahren zur optimierten Nutzung von SCTP (Stream Control Transmission Protocol) in MPLS (Multi Protocol Label Switching) Netzen
JP2003143212A (ja) * 2001-11-01 2003-05-16 Fujitsu Ltd サーバとクラアイントとの接続方法およびルータ装置
EP1355507A1 (de) * 2002-04-19 2003-10-22 Siemens Aktiengesellschaft Verfahren zur Abbildung einer Eigenschaft einer permanenten Verbindung von einem verbindungsorientierten auf ein paketvermittelndes Telekommunikationsnetz
US7918734B2 (en) 2002-09-30 2011-04-05 Time Warner Cable, A Division Of Time Warner Entertainment Company, L.P. Gaming server providing on demand quality of service
US8107373B2 (en) 2003-11-24 2012-01-31 Zte Corporation Method, device and system for realizing QoS guarantee in a MPLS network
US20060092941A1 (en) * 2004-11-01 2006-05-04 Kazuhiro Kusama Communication path monitoring system and communication network system
US8325706B2 (en) 2007-11-26 2012-12-04 Verizon Patent And Licensing Inc. Hierarchical segmented label switched paths
US10218611B2 (en) 2014-06-30 2019-02-26 Juniper Networks, Inc. Label distribution protocol (LDP) signaled multi-protocol label switching rings
US9729455B2 (en) 2014-06-30 2017-08-08 Juniper Networks, Inc. Multi-protocol label switching rings
US9692693B2 (en) * 2014-06-30 2017-06-27 Juniper Networks, Inc. Bandwidth control for ring-based multi-protocol label switched paths
US11233748B1 (en) 2018-08-30 2022-01-25 Juniper Networks, Inc. Bandwidth management for resource reservation label switched path of a ring network

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6021263A (en) * 1996-02-16 2000-02-01 Lucent Technologies, Inc. Management of ATM virtual circuits with resources reservation protocol
US6069889A (en) * 1996-10-02 2000-05-30 International Business Machines Corporation Aggregation of data flows on switched network paths

Also Published As

Publication number Publication date
EE04895B1 (et) 2007-08-15
WO2000036871A1 (en) 2000-06-22
EE200100326A (et) 2002-10-15
SE9804320D0 (sv) 1998-12-15
DE69932851D1 (de) 2006-09-28
NO20012744D0 (no) 2001-06-05
EP1142435A1 (en) 2001-10-10
EP1142435B1 (en) 2006-08-16
SE515465C2 (sv) 2001-08-13
NO20012744L (no) 2001-08-08
SE9804320L (sv) 2000-06-16
DK1142435T3 (da) 2006-12-27
ATE336874T1 (de) 2006-09-15

Similar Documents

Publication Publication Date Title
US7920466B2 (en) Protection of hierarchical tunnel head-end nodes
Osborne et al. Traffic engineering with MPLS
JP3762749B2 (ja) リストレーション・プロテクション方法及び装置
US6477166B1 (en) System, method and switch for an MPLS network and an ATM network
EP1859574B1 (en) Dynamic retrieval of routing information for inter-as te-lsps
US7899044B2 (en) Method and system for optimizing resources for establishing pseudo-wires in a multiprotocol label switching network
US6055561A (en) Mapping of routing traffic to switching networks
US7586841B2 (en) System and method for protecting against failure of a TE-LSP tail-end node
US7756125B2 (en) Method and arrangement for routing pseudo-wire encapsulated packets
NO325719B1 (no) Dataoverforingssystem, samt tilhorende fremgangsmate
Brittain et al. MPLS traffic engineering: A choice of signaling protocols
US8891553B2 (en) Selective label retention in a label switching network
JP3751473B2 (ja) パケット中継装置
Andrikopoulos et al. Supporting differentiated services in MPLS networks
Semeria RSVP signaling extensions for MPLS traffic engineering
US20100091655A1 (en) Method and apparatus for initiating routing messages in a communication network
Cisco Configuring Tag Switching and MPLS
Cisco Configuring Tag Switching and MPLS
WO2002096020A2 (en) Channeling protocol data units
Cisco Configuring Tag Switching and MPLS
Smith Introduction to MPLS
Hunt Evolving technologies for new internet applications
JP3790508B2 (ja) 通信装置，伝送システムおよびパス管理情報回復方法
KR100684143B1 (ko) 단순화된 ｍｐｌｓ 메커니즘을 이용하여 다양한 ｌ2ｖｐｎ서비스를 제공하기 위한 방법 및 장치
Gonzales et al. Using MultiProtocol Label Switching (MPLS) to Improve IP Network Traffic Engineering

Legal Events

Date Code Title Description
MM1K Lapsed by not paying the annual fees