DE10138715A1 - Signalisierter Aufbau von Verbindungssequenzen - Google Patents

Signalisierter Aufbau von Verbindungssequenzen

Info

Publication number
DE10138715A1
DE10138715A1 DE2001138715 DE10138715A DE10138715A1 DE 10138715 A1 DE10138715 A1 DE 10138715A1 DE 2001138715 DE2001138715 DE 2001138715 DE 10138715 A DE10138715 A DE 10138715A DE 10138715 A1 DE10138715 A1 DE 10138715A1
Authority
DE
Germany
Prior art keywords
connection
sequence
tunnel
virtual
label
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
DE2001138715
Other languages
English (en)
Inventor
Heinrich Hummel
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Priority to DE2001138715 priority Critical patent/DE10138715A1/de
Priority to PCT/DE2002/002876 priority patent/WO2003017584A2/de
Publication of DE10138715A1 publication Critical patent/DE10138715A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/34Source routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/54Store-and-forward switching systems 
    • H04L12/56Packet switching systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

In einem Verbindungsnetz, in dem Verbindungsknoten über Verbindungstunnel bildende Verbindungsstrecken verbunden sind, sind mittels einzelner Signalisierungsinformationen Folgen mehrerer Verbindungstunnels zu Transittunnels für einen Datentransport über Folgen von virtuellen Links aufbaubar.

Description

  • Der Anmeldungsgegenstand betrifft ein Verfahren zum Einrichten von Verbindungen in einem Verbindungsnetz, in dem Verbindungsknoten über Verbindungsstrecken verbunden sind.
  • Auf der Grundlage eines physikalischen Kommunikationsnetzes, bestehend aus M1 . . . Mm physikalischen Links und N1 . . . Nn physikalischen Knoten, sollen etliche virtuelle Kommunikationsnetze (VN) eingerichtet werden. Dabei bestehe jedes VN aus einer Menge von Verbindungen (wie etwa m (bidirektionale) ATM(Asynchronous transfer mode)-SVCs (switched virtual circuit, virtuelle Wählverbindung) oder 2.m unidirektionale MPLS (multi protocol label switching)-LSPs), sprich m bzw. 2.m virtuelle Links, welche insgesamt n <=N physikalische Knoten zusammenhängend verbinden. Dabei sei jedem unidirektionalem MPLS-LSP sein ebenfalls unidirektionaler reverser virtueller Link hinzugesellt.
  • Sämtliche Telekommunikationsnetze sind physikalische "partial mesh"-Netze. Eine Vollvermaschung "full mesh" wäre unsinnig. Auf einem physikalischen Netz kann man eine gewisse Menge von Verbindungen bzw. Tunnels etablieren, welche als ganzes gesehen je ein sog. Virtuelles Netz ergeben. Dieses virtuelle Netz umfasse insgesamt n Knoten. Bei Vollvermaschung (full mesh) des virtuellen Netzes würde man n.(n-1)/2 bidirektionale Verbindungen benötigen oder aber n.(n-1) unidirektionale Verbindungen. Auch dieses "virtual full mesh" ist immer noch zu aufwändig (zu teuer).
  • Zum Vergleich ein paar "partial mesh"-Netze: Ein minimalstes virtual partial mesh benötigt lediglich n unidirektionale Verbindungen (= Ring), bzw. n-1 bidirektionale Verbindungen (= Baum). Ein etwas aufwändigeres "Karo"-Netz benötigt lediglich 2.n bidirektionale Verbindungen, bzw. 4.n unidirektionale Verbindungen.
  • Anwendungsbeispiele
    • a) Virtual Privat Network (VPN). Genauer: das Verbindungsnetz zwischen den n Standorten einer Privatfirma, welches das "öffentliche Netz" überbrückt.
    • b) Virtual Service Provider Network (VSPN). Genauer: Das Verbindungsnetz zwischen den n Switches/Routers eines Service Providers, welches das Netz eines anderen Service Providers überbrückt. Dieses Verbindungsnetz wird auch Carrier's Carrier Network genannt.
    • c) VPN basierend auf einem VSPN Netzes
    • d) MPOA Overlay-Model des ATM Forums: Applikationen: Im Multi-Protocol-over-ATM (MPOA) Modell des ATM Forums wird eine Menge von ATM-SVC-Verbindungen benützt, um ein ATM-Netz quasi als Transitnetz des Internets zu benutzen. Die ATM-Switche sind zudem mit Internet-Routern verbunden. Man transportiert IP-Pakete in Form von ATM- Zellen durch das ATM-Netz, um sie danach als IP-Pakete in einem IP-Netz weiterzuleiten. Bisherige Lösungen: a) Full mesh d. h. n.(n-1)/2 SVCs, oder b) SVC-Management, welche maximal m SVCs einrichten kann. Wird ein SVC benötigt, der noch nicht existiert, so wird dieser aufgebaut sofern das Maximum m noch nicht erreicht ist. Andernfalls wird entweder der Übertragungswunsch zurückgewiesen oder aber es wird eine existierende SVC abgebaut um "Platz zu schaffen" - etwa eine SVC, die relative wenig Verkehrslast hat.
  • Im Falle von "partial mesh" müssen die zu transportierenden Nutzdaten eine gewisse Folge von Verbindungstunnels passieren um zu einem vorbestimmten Zielknoten zu gelangen.
  • Dem Anmeldungsgegenstand liegt das Problem zugrunde, eine Quasivollvermaschung herzustellen, selbst wenn die Vollvermaschung, etwa aus Einsparungsgründen, bei weitem unterschritten ist.
  • Das Problem wird durch die Merkmale des kennzeichnenden Teils des Anspruchs 1 gelöst.
  • Beim Anmeldungsgegenstand werden also mehrere Verbindungsstrecken zu Sequenzen von Verbindungstunnels aufgebaut und als Transittunnels eingesetzt, wobei dann Folgen von virtuellen Links beim Datentransport durchlaufen werden können.
  • Beim Anmeldungsgegenstand werden vorteilhafterweise eine Menge von Tunnelverbindungen eingespart.
  • Vorteilhafte Weiterbildungen des Anmeldungsgegenstandes sind in den Unteransprüchen angegeben.
  • Eine derartige Sequenz kann ihrerseits als Tunnel betrachtet werden.
  • Dies lässt sich rekursiv noch weiter steigern.
  • Dies führt zu dem Begriff des Hierarchischen Tunnels (von einer gewissen Hierarchiestufe). Ein hierarchischer Tunnel ist also eine aufgebaute Sequenz von Bestandteils-Tunnels = Element-Tunnels.
  • "Aufbau" oder "aufgebaute Sequenz" soll heissen: Es werden Tunnelverknüpfungseinstellungen gemacht (= Label switching entries) derart, dass der Nutzdatenstrom die einzelnen Tunnels genauso schnell und einfach wechseln kann wie die Leitungen innerhalb eines Tunnels.
  • Der Anmeldungsgegenstand wird im folgenden als Ausführungsbeispiel in einem zum Verständnis erforderlichen Umfang anhand von Figuren näher erläutert. Dabei zeigen:
  • Fig. 1 eine abstrahierende Darstellung eines Vermittlungsnetzes, in dem die Erfindung realisierbar ist und
  • Fig. 2 erfindungsgemäße Besonderheiten bei der Bildung von Folgen von Verbindungsstrecken.
  • In Fig. 1 stellen die dünnen Linien physikalische Verbindungsstrecken und deren Knotenpunkte physikalische Router eines Vermittlungsnetzes dar. Die durchgehenden Pfeile bezeichnen unidirektionale Verbindungsstrecken (Links) und die unterbrochenen Pfeile hops des hierarchischen Mehrpunkt zu Punkt LSP (LSP = label switched path).
  • Die einzelnen Verbindungen/Tunnels können von verschiedenster Technologie sein:
    ISDN-Verbindung, ATM-SVC, Frame-Relay-SVC, MPLS-LSPs, Internet-Tunnels gemäß der IETF Standards wie IPSEC, L2TP, PPP, GRE, IP in IP. Ein per Signalisierung aufgebaute Verbindung/Tunnel-Sequenz kann Technologie -heterogen sein.
  • In einer bevorzugten Ausführungsform ist eine per Signalisierung aufgebaute Verbindung/Tunnel-Sequenz unabhängig von dem(n) zum Einsatz kommenden Übertragungsstandard(s).
  • Folgende Verbindung/Tunnel-Sequenzen sind aufbaubar: point- to-point Sequenz, point-to-multipoint Sequenz, multipoint-to- point Sequenz.
  • Point-to-multipoint: Die Nutzdaten durch die aufgebaute baumartige Tunnelsequenz fließen von einem Sender- Tunnelausgangspunkt hin zu mehreren Empfänger-Tunnelendpunkten.
  • Multipoint-to-point: Die Nutzdaten durch die aufgebaute baumartige Tunnelsequenz fließen von mehreren Sender- Tunnelausgangspunkten hin zu einem Empfänger-Tunnelendpunkt.
  • Der Aufbau einer i. A. baumartigen Verbindung/Tunnel-Sequenz kann entweder von der Baum-Wurzel hin zu den Blättern erfolgen oder aber beginnend bei den Blättern hin zur Wurzel (= reverse path setup). Beide Varianten kommen sowohl für point-to-multipoint als auch für multipoint-to-point Tunnelsequenzen in Betracht.
  • Der Anmeldungsgegenstand ist in Unidirektionalität und Bidirektionalität der Verbindungen/Tunnels gleichermaßen ausführbar.
  • Rekursivität
  • Ein hierarchischer Tunnel von niedrigster (= erster hierarchischer Stufe) besteht aus einer linearen Folge von Hops entlang physikalischer Leitungen. Ein Tunnel von einer höheren hierarchischen Stufe besteht aus einer linearen Folge von Element-Tunnels einer niedrigeren Hierarchiestufe.
  • Die Element-Tunnel einer baumartigen Tunnelsequenz können z. B. Tunnels der 1. Hierarchiestufe sein (VPN über dem physikalischen Netz eines Service Providers.)
  • Die Element-Tunnel einer baumartigen Tunnelsequenz könnten . aber auch von einer höheren Hierarchiestufe sein (VPN über einem Virtuellen Service Provider Netz).
  • Zu jedem Element-Tunnel gehören ihn identifizierende und charakterisierende Daten der Sorte "global signifikant" als auch der Sorte "lokal signifikant".
  • Die global signifikanten Daten mögen umfassen:
    Ru = Routeradresse des upstream-Tunnelendpunktes (wo die Nutzdaten in den Tunnel hineingehen),
    Rd = Routeradresse des downstream-Tunnelendpunktes (wo die Nutzdaten den Tunnel verlassen),
    Color = abstrakte Zusammenfassung aller charakterisierenden Eigenschaften wie Bandbreite, QoS (Quality of Service), Zweckbestimmung wie "for voice" oder "for data", usw. Die (unterschiedliche) Color wird bedeutsam vor allem wenn es mehrere parallele Tunnels mit identischem Ru und identischem Rd gibt.
  • LSP-ID (Label switched path identifier) (= Tunnel- Identifizierer)
  • Sie besteht aus der Adresse Ru plus einer von diesem upstream Router vergebene Zahl.
  • Wir wollen dazu kommen, dass die aufzubauende Tunnelsequenz gleichsam aus höherer Warte aus, wie nur ein Tunnel angesehen wird und somit auch eine LSP-ID bekommt genauso wie jeder ihrer Elementtunnel. Diese LSP-ID wird, erfindungsgemäß, vom Router am downstream-Ende der Tunnelsequenz vergeben.
  • Die global signifikanten Daten von vielen Tunnels (wie z. B. sämtlicher Tunnels, welche exklusiv für ein ganz bestimmtes VPN benutzt werden) mögen - statisch oder dynamisch - einem Prozeß zugespielt werden, welcher gewisse Tunnelsequenzen daraus bestimmen möge.
  • Lokal signifikante Daten eines Tunnels
  • Dies sind die Label switching entries für das jeweilige Tunnel-Switching. An den Tunnelendpunkten sind sie auffindbar anhand der Tunnel-ID.
  • Aber auch die jeweilig aufgebaute Tunnelsequenz (welche aus diesen Element-Tunnels besteht) bekomme ihrerseits solche global und lokal signifikante Daten.
  • Label-Vergabe
  • Ein Label vergibt der downstream-Router. Er sagt dem upstream-Router "mit diesem Label versehen sollst du mir die Nutzdatenpakete zuschicken".
  • Eine Tunnelsequenz kann als aufgebaut betrachtet werden, wenn folgendes installiert = gespeichert ist:
  • LIB-Eintrag am Router des upstream-Endes der Tunnelsequenz (LIB = Label Information Base)
    • a) Suchschlüssel (Vergleichs-Wert) um den LIB-Eintrag finden zu können:
      FEC-Information sprich welche Zieladressenbereiche sind am downstream-Ende der Tunnelsequenz zu erreichen (FEC = Forwarding Equivalenz Class)
    • b) Gesuchtes:
      Label bzgl. des ersten Tunnels der Tunnelsequenz;
      Label des ersten Hops des ersten Tunnels;
      Physikalische Leitung (interface index) des ersten Hops des ersten Tunnels;
      LIB-Eintrag am Router der die Daten über einen incoming Tunnel empfängt und sie über einen outgoing Tunnel weiterleitet:
      Suchschlüssel (Tabellenindex-Wert)um den LIB-Eintrag finden zu können:
      Label des incoming Tunnels
    • c) Gesuchtes:
      Label bzgl. des outgoing Tunnels der Tunnelsequenz;
      Label des ersten Hops des outgoing Tunnels;
      Physikalische Leitung (interface index) des ersten Hops des outgoing Tunnels.
  • Sollte der Element-Tunnel seinerseits bereits eine Sequenz von noch elementareren Tunnels darstellen, so ist unter Gesuchtes noch ein weiteres Label (an zweiter Position) aufzusuchen.
  • Der Aufbau der Tunnelsequenzen erfolgt per Signalisierung.
  • Der Aufbau einer sich nicht verzweigenden/sich nicht vereinigenden Tunnelsequenz - sprich einer linearen Tunnelsequenz - erfolgt im Prinzip identisch wie beim Aufbau eines Tunnels der allerersten Hierarchiestufe.
  • Aus Elementtunnels eines VPNs werden sich vereinigende Tunnelsequenzen aufgebaut, welche - egal bei welchem Ausgangsknoten beginnend - die Nutzdaten hin zu einem vorbestimmten Zielknoten transportierbar sind.
  • Für jeden einzelnen Knoten Z (wie Ziel) des VNs stellt sich die Frage: "über welche Folge von virtuellen Links sollte jeder der übrigen n-1 Knoten S (wie Start) des VNs Übertragungsdaten zu ihm hintransportieren?" Insgesamt bilden all diese Folgen von virtuellen Links einen Baum welcher in Z wurzelt.
  • An allen Knoten, welche in diesem Baum vorkommen, sollen "Einstellungen" vorgenommen werden, derart daß der Datentransport wie gewünscht ablaufen kann. Die Summe dieser Einstellungen ergibt eine sogenannte hierarchische Mehrpunkt-zu- Punkt Verbindung.
  • Ein hierarchischer Mehrpunkt-zu-Punkt LSP ermöglicht folgendes:
    Ein beliebiger Knoten S sendet Daten, welche für Z bestimmt sind, indem er diesen zwei MPLS-Labels mitgibt. Das im Labelstack obere Label sei zuständig für das Label-Switching am nächsten physikalischen Knoten des ersten virtuellen Links, d. h. es wird im nächsten physikalischen Knoten verwendet um den physikalischen Fortsetzungslink zu bestimmen sowie das Fortsetzungslabel.
  • Das untere Label wird transparent sprich unverändert mitgeführt bis hin zum Ende des ersten virtuellen Links. Dort wird das obere Label entfernt und das untere Label benutzt, um an folgende Informationen heranzukommen: vom richtigen virtuellen Folgelink (in Richtung Z) die erste physikalische Leitung sowie dessen erstes Label (welches als neues obere Label fungieren soll). Ferner ein neues unteres Label, welches am Ende des zweiten virtuellen Links wie gerade beschrieben fungieren soll.
  • Im Falle von ATM gilt alles ganz analog, wobei 2 Möglichkeiten realisierbar sind:
    • 1. Das obere Label ist ein VPI (virtual path identifier), das untere Label ist ein VCI (virtual channel identifier). Mit anderen Worten: Die virtuellen Links sind SVPs. Die baumartige Folgen von SVPs bilden einen hierarchische Mehrpunkt-zu-Punkt SVC.
    • 2. Das obere Label ist ein VCI, das unter Label ist ein VPI. Mit anderen Worten: Die virtuellen Links sind SVCs. Die baumartige Folgen von SVCs bilden einen hierarchischen Mehrpunkt-zu-Punkt SVP.
  • Bevor man die hierarchischen Mehrpunkt-zu-Punkt Verbindungen aufbauen kann, müssen erst einmal die hierbei "auszunützenden" Basis-Verbindungen, sprich die virtuellen Links, bekannt und aufgebaut sein.
  • Jedem virtuellen Link sei ein eindeutiger ID zugeordnet. Er bestehe aus "Adresse seines Ingress-Knotens + einer eineindeutigen, von diesem selbst vergebenen Nummer". Dabei müssen die IDs zweier virtueller Links auch dann unterschiedlich sein wenn diese unterschiedlichen VNs angehören.
  • Im Falle von MPLS muß zu jedem virtuellen Link auch ein diesbezüglich inverser, geeigneter virtueller Link in Form seiner ID bekannt sein. Geeignet heißt: sie müssen beide demselben VN angehören (nur die gleichen Endpunkt-Knoten haben, sollte nicht hinreichend sein).
  • Dieses Zuordnungswissen müssen insbesondere die beiden Endknoten des jeweiligen virtuellen Links besitzen und auswerten können, aber auch jeder Knoten Z (oder hierfür ein VN- zentraler Proxy-Server), welcher den Baum einer hierarchischen Mehrpunkt-zu-Punkt Verbindung bestimmen soll.
  • Der Zielknoten Z berechnet sich den Baum von virtuellen Links (oder läßt sich diesen von einem z. B. VN-zentralen Server berechnen).
  • So wie es mehrere parallele virtuelle Links geben kann (z. B. einen für Daten, einen zweiten für Sprache), so kann es mehrere hierarchische Mehrpunkt-zu-Punkt Verbindungen mit identischem Zielknoten geben (z. B. eine für Daten, eine zweite für Sprache).
  • Es gibt zahlreiche Möglichkeiten wie diese Hierarchische Mehrpunkt-zu-Punkt Verbindung aufgebaut werden kann:
  • 1) In einem MPLS-Netz mit unidirektionalen virtuellen Links 1a) "Von Z hin zu n-1 Startknoten in einem einzigen Vorgang
  • Ausgehend von Z wird eine minimale Anzahl von Aufbaumeldungen (z. B. so viele virtuelle Links als bei Z angrenzen) ausgesendet und diese dabei mit einer Source Routing Information versehen, welche den bevorstehenden Verzweigungen genügt. Im Falle von MPLS-LDP könnten dies "unsolicited" Label_Mapping Meldungen sein.
  • Knoten Z schicke eine "unsolicited" Label_Mapping Meldung aus. Sie beinhalte ein geeignetes TREE ROUTE TLV welches den zu beschreitenden Verzweigungen entspricht. Sie beinhalte ferner z. B. in einem eigens definierten Passed_Virtual_Link- TLV den ID desjenigen virtuellen Links über den die user- Daten beim Knoten Z eintreffen sollen.
  • Was die Source Routing Information betrifft, so kommt hier neu der hierarchische Aspekt hinzu: Die einzelnen ER-HOP TLVs in der Source Routing Information (TREE ROUTE TLV) mögen stets die IDs zweier inverser virtueller Links enthalten, nämlich den ID des uplinks (in Richtung S) sowie den ID des virtuellen downlinks (in Richtung Z). Bei der Berechnung des Baumes mit Wurzel Z sei darauf geachtet worden, daß alle downlinks den Anfordernissen der user-Datenübertragung genügen, d. h. daß z. B. von mehreren parallelen downlinks genau der richtige bestimmt wird. Der diesbezügliche (inverse) uplink aber mag irgendeiner sein, oder aber stets der erstgelistete oder aber einer der "für Daten" gekennzeichnet ist.
  • Angenommen ein Knoten K-down habe die Label-Mapping Meldung für den Aufbau eines Hierarchischen Mehrpunkt-zu-Punkt-TLVs empfangen und müsse ein ganz bestimmtes ER-HOP TLV auswerten (falls sich in K-down x virtuelle Links vereinigen sollen, so sind es x ER-HOP TLVs). Über die ID des uplinks erfährt er die physikalische Startleitung samt Start-Label um die Meldung, angemessen modifiziert, label switched über den uplink zum Knoten K-up zu befördern. Bevor er dies aber tut, bestimmt er ein verfügbares Label Vincoming bzgl. des gesamten virtuellen downlinks, welches er per Label-TLV dem Knoten K- up mitzuteilen gedenkt. Der Knoten K-down hat selbst per Label-TLV ein Label Voutgoing erhalten. Knoten K-down entnehme dem Passed_Virtual_Link-TLV der selbst empfangenen Aufbaumeldung die ID desjenigen virtuellen Links, den er benutzen soll um die user-Daten in Richtung Z weiterzuleiten. Von diesem virtuellen Link kennt er selbstverständlich die physikalische Startleitung poutgoing samt Start-Label Poutgoing. Er erzeugt einen Label-Information-Base-Eintrag (LIB-Eintrag), welcher mittels Vincoming aufgesucht werden kann und in welchem steht:
    "Ersetze durch Vincoming durch Voutgoing und pushe danach Poutgoing in den Labelstack und schicke das Datenpaket mit beiden Labels über poutgoing weiter".
  • K-down schickt die Label-Mapping weiter an K-up, wobei er in das Passed_Virtual-Link TLV den ID desjenigen virtuellen Links schreibt, über welchen er die user-Daten von K-up zu empfangen gedenkt.
  • Falls sich x virtuelle Links in K-down vereinigen sollen, so bestimmt er für jeden der x "incoming"-Links ganz analog ein verfügbares Label Vincoming sowie einen LIB-Eintrag in welchem steht:
    "Ersetze DIESES Vincoming durch Voutgoing und pushe danach Poutgoing in den Labelstack und schicke das Datenpaket mit beiden Labels über poutgoing weiter".
    In diesem Falle wird jedem der x verschiedenen Knoten K-up per Passed_Virtual_Link-TLV der ID des jeweiligen virtuellen Links mitgeteilt, über den dieser die user-Daten an K-down senden soll.
  • 1b) Von Z hin zu n-1 Startknoten in n-1 zeitlich versetzten Vorgängen
  • Ausgehend von Z werden n-1 Aufbaumeldungen im zeitlichen Hintereinander ausgesendet um stets genau einen Ast hin zu genau einem Startknoten S gemäß des "ADD-PARTY/SETUP"-Konzept des ATM Forums sukzessive aufzubauen.
  • Um sich mehr an die MPLS-Terminologie anzulehnen, so sei auch hier die Aufbaumeldung eine sogenannte unsolicited Label-Mapping Meldung. Sie enthalte zweierlei Source Routing Informationen
    • 1. Ein ER-TLV, deren ER-HOP TLVs stets nur die IDs der jeweiligen uplinks enthält.
      Diese werden benutzt um die Meldung über jene virtuellen uplinks hinweg zu befördern, deren zugehörigen downlinks bereit bei der bislang aufgebauten hierarchischen Mehrpunkt-zu-Punkt Verbindung bereits berücksichtigt worden sind. (für den "ADD PARTY" Abschnitt)
    • 2. Ein ER-TLV, deren ER-HOP TLVs wie oben beschrieben die beiden IDs des jeweiligen uplinks plus downlinks enthalten (für den "SETUP" Abschnitt).
  • Im Passed_Virtual_Link-TLV stehe die ID desjenigen downlinks, welcher invers ist zum allerletzten uplink des ersteren ER- TLVs, sprich die ID desjenigen virtuellen Links, welcher bereits in die Hierarchische Mehrpunkt-zu-Punkt Verbindung eingebunden ist und in welchem der aktuelle Erweiterungszweig einmünden soll.
  • Bei denjenigen Aufbaumeldungen, welche einen Ast bis hin zum Knoten Z aufbauen entfällt das erstere ER-TLV. Im Passed_Virtual_Link-TLV stehe dann die ID desjenigen downlinks über den Z die User-Daten empfangen soll.
  • 1c) Von den n-1 Startknoten hin zu Zielknoten Z
  • Ausgehend von Z werden Meldungen an die n-1 Knoten S geschickt, welche enkapsuliert "Join"-Meldungen enthalten, welche entsprechend der darin enthaltenen Punkt-zu-Punkt förmigen Source Routing Informationen je einen Zweig in Richtung Z aufbauen sollen - quasi nach dem Prinzip des "reverse path setups". All diese "Join"-Meldungen müssen ein und dieselbe Identifizierung für die gemeinschaftlich zu erstellende Hierarchische Multipunkt-zu-Punkt Verbindung enthalten, etwa bestehend aus einem Doublet "Adresse von Z+ einer von Z vergebener eindeutiger Nummer". Diese ID muß eindeutig sein auch angesichts zahlreicher gleichzeitig vorhandener VNs.
  • Sobald eine "Join"-Meldung bei einem Knoten ankommt, an dem bereits eine frühere Join mit selbiger LSP-ID vorbeigekommen ist, so darf sie nicht mehr in Richtung Z weitergeleitet werden.
  • Die Join-Meldung enthalte genau ein ER-TLV (Explicit Route TLV) deren ER-HOP TLVs, die IDs der zu passierenden virtuellen Links sind. Die Label- Zuteilung muß nach dem independent mode geschehen - alles andere wäre Unfug angesichts der Existenz der Varianten 1a) und 1b). D. h. Jede Join-Meldung ist ähnlich wie eine Label_Request, welche nach jedem HOP eine Label-Zuteilung macht und diese genau einen Hop wieder zurück in Richtung Knoten S meldet (mittels einer Label-Mapping Meldung), um dort den passenden LIB- Eintrag vorzunehmen.
  • Die Join-Meldung verwende für das eigene Vorankommen die virtuellen Links, die auch für den User-Datenstrom vorgesehen sind. Ein Passed_Virtual_Link-TLV möge dabei die ID desjenigen virtuellen Links (downlinks) enthalten, den die Join Meldung soeben benützt hat. Ein Knoten K-down, der sie soeben empfangen hat, wird die ID eines diesbezüglich inversen virtuellen Links (uplink) feststellen können und darüber eine Label-Mapping Meldung genau einen Hop zurück in Richtung S schicken können. Diese werde ausgestattet mit einem Label-TLV in welches K-down ein nach dem Prinzip des independent modes selbst vergebenes Label Vincoming eingetragen hat. K-down wartet seinerseits auf eine Label-Mapping Meldung und erwartet von dort das analoge Label Voutgoing. Außerdem kennt es die ID des unmittelbar in Richtung Z führenden virtuellen Links, und somit dessen Startleitung poutgoing samt Start-Label Poutgoing aufgrund des ersten erhaltenen ER- HOP TLVs.
  • K-down bildet den LIB-Eintrag, welcher mittels Vincoming aufgesucht werden kann und welcher beinhaltet:
    "Ersetze Vincoming durch Voutgoing und pushe danach Poutgoing in den Labelstack und schicke das Datenpaket mit beiden Labels über poutgoing weiter".
  • 2) In einem ATM-Netz mit bidirektionalen virtuellen Links
  • Es bietet sich die in 1b) beschriebene Methode an. Statt ER- HOP TLVs hat man es mit PNNI DTLs zu tun.
  • Bei Vollvermaschung hat man ein VN, wobei die Anzahl der virtuellen Links von der Ordnung n2.
    Quasi-Vollvermaschung benötigt man lediglich von der Ordnung n viele virtuelle Links.
    Das VN könnte sowohl ein Virtual Service Provider Network (VSPN) als auch ein Virtual Private Network (VPN) sein. Ferner:
    VSPNs könnten ihrerseits VPNs betreiben. Das VSPN bestehe aus einer Menge von virtuellen Links 1. Grades.
  • Ein von ihm betriebenes VPN bestehe aus virtuellen Links 2. Grades. So ein virtueller Link 2. Grades besteht im allgemeinen aus mehreren virtuellen Links vom 1. Grad. Der virtuelle Link 2. Grades ist eine Hierarchische 1-Punkt-zu-Punkt Verbindung, dessen Aufbau genauso funktioniert wie der Aufbau der oben geschilderten Hierarchischen (n-1)Mehrpunkt-zu-Punkt Verbindung, sprich n = 2 d. h. n-1 = 1.
  • Die Quasivollvermaschung eines derartigen VPNs würde erst vermöge Hierarchischer Mehrpunkt-zu-Punkt Verbindungen ermöglicht, welche baumartig virtuelle Links des 2. Grades derart aneinander koppeln, daß die user-Daten nach Z und zwar total label switched, transportiert werden können.
  • Typisch dabei sind LIB-Eintragungen der Art:
    "Ersetze Vincoming durch Voutgoing und pushe zudem die Labels Woutgoing und Poutgoing in den Labelstack und schicke das Datenpaket mit beiden Labels über poutgoing weiter". Hierbei sei Woutgoing das Label bzgl. des ersten virtuellen Links 1. Grades vom diesbezüglichen virtuellen Link 2. Grades.
  • Weiteres Einsatzmöglichkeiten liegen auf dem Gebiet des Traffic Engineerings:
    Ein Administrator hat bereits, aus welchem Grund auch immer, zahlreiche Tunnels (= virtuelle Punkt-zu-Punkt Links) installiert. Zu einem späteren Zeitpunkt möchte er, anstatt neuer solcher Tunnels 1. Grades zu etablieren, die vorhandenen ausnutzen und gewisse Tunnelfolgen als quasi neuen Tunnel etablieren.

Claims (9)

1. Verfahren zum Einrichten von Verbindungen in einem Verbindungsnetz, in dem Verbindungsknoten (N1 . . . Nn) über Verbindungsstrecken (M1 . . . Mm) verbunden sind, dadurch gekennzeichnet, dass mittels Signalisierung auf eine einzelne Signalisierungsinformation hin eine Folge von mehreren Verbindungsstrecken einrichtbar ist.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass eine per Signalisierung aufgebaute Verbindung/Tunnel-Sequenz unabhängig von dem(n) zum Einsatz kommenden Übertragungsstandard(s) ist.
3. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass zwischen genau einem Start-Verbindungsknoten und genau einem Ziel-Verbindungsknoten die Folge von mehreren Verbindungsstrecken eingerichtet wird.
4. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass zwischen genau einem Start-Verbindungsknoten und mehreren Ziel-Verbindungsknoten die Folge von mehreren Verbindungsstrecken eingerichtet wird.
5. Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass zwischen mehreren Start-Verbindungsknoten und genau einem Ziel-Verbindungsknoten die Folge von mehreren Verbindungsstrecken eingerichtet wird.
6. Verfahren nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass der Aufbau einer Verbindung/Tunnel-Folge von dem genau einen Verbindungsknoten zu den mehreren Verbindungsknoten erfolgt.
7. Verfahren nach einem der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass der Aufbau einer Verbindung/Tunnel-Folge von den mehreren Verbindungsknoten zu dem genau einen Verbindungsknoten erfolgt.
8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Bezeichnung (LSP-ID) für die Verbindung/Tunnel-Sequenz von dem Netzknoten am zielseitigen (downstream)-Ende der Verbindung/Tunnel-Folge vergeben wird.
9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass eine Folge von Verbindungsstrecken als Einheit zusammen mit zumindest einer weiteren Verbindungsstrecke eine neue einheitliche Folge bildet.
DE2001138715 2001-08-07 2001-08-07 Signalisierter Aufbau von Verbindungssequenzen Withdrawn DE10138715A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE2001138715 DE10138715A1 (de) 2001-08-07 2001-08-07 Signalisierter Aufbau von Verbindungssequenzen
PCT/DE2002/002876 WO2003017584A2 (de) 2001-08-07 2002-08-05 Signalisierter aufbau von verbindungssequenzen

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2001138715 DE10138715A1 (de) 2001-08-07 2001-08-07 Signalisierter Aufbau von Verbindungssequenzen

Publications (1)

Publication Number Publication Date
DE10138715A1 true DE10138715A1 (de) 2003-02-20

Family

ID=7694647

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2001138715 Withdrawn DE10138715A1 (de) 2001-08-07 2001-08-07 Signalisierter Aufbau von Verbindungssequenzen

Country Status (2)

Country Link
DE (1) DE10138715A1 (de)
WO (1) WO2003017584A2 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2239032A1 (en) * 1998-05-28 1999-11-28 Newbridge Networks Corporation Operator directed routing of soft permanent virtual circuits in a connection-orientated network
US6985447B2 (en) * 2000-10-20 2006-01-10 Nortel Networks Limited Label switched traffic routing and signaling in a label switched communication packet network

Also Published As

Publication number Publication date
WO2003017584A3 (de) 2003-07-10
WO2003017584A2 (de) 2003-02-27

Similar Documents

Publication Publication Date Title
DE69727930T2 (de) Zusammenfassung von verbindungen in vermittlungskommunikationsnetzen
DE60122457T2 (de) System und Verfahren zum Herstellen eines Kommunikationsweges auf einer ATM Plattform
DE60103338T2 (de) Etikettvermitteltes Kommunikationsnetzwerk
DE60102047T2 (de) Etikettvermitteltes Kommunikationsnetzwerk
DE60112700T2 (de) System und Verfahren zum Betreiben eines Netzwerks auf einer ATM-Plattform
DE69919569T2 (de) Verwaltung von verbindungsorientierten diensten über das internet-protokoll
DE69808753T2 (de) Mehrfachübertragungsvermittlung und -verfahren
DE60037368T2 (de) Verfahren und Architektur zur Unterstüzung von mehreren Diensten in einem Etikettvermittlungsnetzwerk
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE69734258T2 (de) Anordnung und Verfahren zur hierarchischen Mehrfachsende-Leitweglenkung in einem ATM-Netz
DE69938570T2 (de) Verfahren und Vorrichtung für eine reservierte und dynamische Dienstqualität in einem Kommunikationsnetz
DE69637290T2 (de) Verbindungsreservation in Kommunikationsnetzwerken
DE102007022704B4 (de) Verfahren zum Einrichten eines logischen Verbindungspfads in einem verbindungsorientierten paketvermittelten Kommunikationsnetzwerk
DE69737342T2 (de) Internet-NCP(Netzwerksteuerungspunkt) über ATM
DE69916747T2 (de) Verfahren zur Bereitstellung von Dienstgüte in IP-Netzwerken für verzögerungsempfindliche Verkehr
DE60035969T2 (de) Verfahren und Anordnung zur Behandlung der Informationpakete durch vom Nutzer auswählbare Relaisknoten
DE60022602T2 (de) Verfahren, Vorrichtung und Computerprogramm um Topologiedaten eines Link State Routing Netzwerkes aktuell zu halten
DE69333395T2 (de) Verfahren und Geräte zur Verbindung lokaler Netze mit Großraum-Hauptnetzen
DE60205748T2 (de) Mehrfachsendung in punkt-zu-punkt-paketdatennetzwerken
DE60029430T2 (de) Mehrfach-sendefähiges adressauflösungsprotokoll
DE69220564T2 (de) Unterstützung von verbindungslosen Diensten im ATM-Netz unter Verwendung von Teilverbindungen
DE60210574T2 (de) Netzwerkauswahl für eine Verbindung
DE69833497T2 (de) Zusammenfügen von virtuellen pfaden in einem mehrpunkt-zu-punkt-netzwerk-tunnel-protokoll
DE60318221T2 (de) Netzwerk und Verfahren zur Bereitstellung von Schicht-2 virtuellen privaten Netwerken auf Basis von vermittelten virtuellen Verbindungen
DE60012736T2 (de) Verfahren zur leitwegerzeugung für mehrfachdatenverkehr

Legal Events

Date Code Title Description
8139 Disposal/non-payment of the annual fee