DE10232945A1 - Differentiated Routing-Auswahl einer von mehreren Routingtabellen mittels Codepoint im IP-Header - Google Patents
Differentiated Routing-Auswahl einer von mehreren Routingtabellen mittels Codepoint im IP-Header Download PDFInfo
- Publication number
- DE10232945A1 DE10232945A1 DE2002132945 DE10232945A DE10232945A1 DE 10232945 A1 DE10232945 A1 DE 10232945A1 DE 2002132945 DE2002132945 DE 2002132945 DE 10232945 A DE10232945 A DE 10232945A DE 10232945 A1 DE10232945 A1 DE 10232945A1
- Authority
- DE
- Germany
- Prior art keywords
- routing table
- identifier
- internet protocol
- sst
- traffic
- 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
Links
Classifications
-
- 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/12—Shortest path evaluation
-
- 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/302—Route determination based on requested QoS
-
- 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/38—Flow based routing
-
- 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/56—Routing software
- H04L45/566—Routing instructions carried by the data packet, e.g. active networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
In einem verbindungslosen Kommunikationsnetz werden die DSCP(Differentiated Service Code Point)-Bits im Header der IP(Internet Protocol)-Pakete auch dazu genutzt, um im jeweils passierten Transit-Router eine spezielle Routingtabelle auszuwählen, in welcher die geeignete Leitung für das Weiterleiten des IP-Pakets gesucht wird. Die hierbei verschiedenen Routingtabellen entsprechen quasi verschiedenen Verkehrswegestrukturen innerhalb des Netzes. Verkehrsbalancierung, QoS-/Policy-Routing, all dies läßt sich hiermit erreichen, ohne daß Verbindungszustandsspeicher (states) in den einzelnen Netzknoten angelegt werden müssen.
Description
- Der Anmeldungsgegenstand betrifft ein Verfahren zur Weiterleitung von IP-Paketen in einem verbindungslosen Kommunikationsnetzwerk.
- Bei der Internetdatenübertragung werden die IP-Pakete im allgemeinen nach dem Shortest-Path-Forwarding (SPF) Routingprinzip auf der „Kürzesten Route" weitergeleitet.
- Hierfür unterhält heutzutage jeder Router genau eine Routingtabelle.
- Eine Übertragung über davon abweichende Wege kann erforderlich werden auf Grund von QoS-Anforderungen (Quality of Service), Policy-Anforderungen (Marktverhalten des Netzbetreibers) oder Bandbreiten-Bedarf/-Verfügbarkeit.
- Dann aber mußte bisher eine Art Verbindung aufgebaut werden, wobei für die Dauer der Übertragung ein Verbindungsspeicher („state") in den zu passierenden Routern/Switche angelegt werden muss (siehe RSVP Resource Reservation Protocol, siehe MPLS Multiprotocol Label Switching), veranlasst von Verbindungsaufbaumeldungen (PATH/RESERVE bzw. LABEL_REQUEST/LABEL_MAPuPING). Diese states werden als nicht skalierbar beurteilt.
- Ein alternativer Lösungsansatz, der diese states vermeidet, ist durch Differentiated Services (DiffServ) gegeben, wobei IP-Pakete unterschiedlich markiert werden, so dass sie in den passierten Routern eine unterschiedlich priorisierte Behandlung genießen können. Siehe RFCs 3086, 3140, 3246, 3260. Siehe auch McGraw-Hill Encyclopedia of Networking and Telecommunications, 2001, Seiten 350 ff.
- Die vorliegende Erfindung verfolgt das Ziel, daß die mit unterschiedlicher Markierung versehenen IP-Pakete nicht nur unterschiedlich priorisiert behandelt, sondern darüber hinaus auch unterschiedlich geroutet werden können, wobei auch weiterhin keinerlei Verbindungspeicher (=states) angelegt werden müssen.
- Das Ziel wird durch die Merkmale des Anspruchs 1 erreicht.
- Erfindungsgemäß erhält also jedes IP-Paket eine Markierung bzw. Kennung, nachfolgend mit DiffRout Codepoint (DRCP) bezeichnet. Erfindungsgemäß unterhält der einzelne Router nicht nur eine Routingtabelle sondern mehrere, wobei die jeweils heranzuziehende Routingtabelle auf Grund des DRCP-Wertes im Header des ankommenden IP-Pakets selektiert wird.
- Der DRCP könnte z.B. in den sechs DSCP-Bits untergebracht sein, so daß diese zum einen als DiffServ Codepoint, daneben aber auch als DiffRout Codepoint zu interpretieren wären. Allgemeiner: Der DRCP könnte den IP-Paketen mitgegeben werden, wobei zu seiner Erkennung der Protocol-Type, die sechs DSCP-Bits, die zwei CU-Bits, im Falle von IPv6 das Flow Label, oder aber Teile davon herangezogen werden müssen.
- Eine Überlagerung der DSCP-Bits mit einer weiteren Bedeutung („differentiated routing" zuzüglich zu „differentiated service") verkompliziert die Dinge zwar ein bißchen, ist aber durchaus machbar, weil man a) keine 2**6=64 differentiated services braucht (ein Kunde zahlt nur für derartige differentiated services, deren Qualitätsunterschiede er auch tatsächlich wahrnehmen und spüren kann), und weil b) die neue Zusatzbedeutung die gewollten und bisher erzielten DiffServ-Effekte geradezu verstärkt.
- Die Erfindung bietet die Möglichkeit, auf einem vorgegebenen Netz unterschiedliche Verkehrswegestrukturen zu definieren, etwa in Analogie zum Straßensystem, wo bestimmte Ver kehrsteilnehmer, etwa die Fußgänger, bevorzugt Gehwege, daneben aber auch Landstraßen, auf keinen Fall aber Autobahnen benutzen dürfen, oder wo Autos Landstraßen, Autobahnen, und nur bei Bezahlung auch Mautstraßen, andererseits aber keine Gehwege befahren dürfen, usw.
- In diesem Sinne lassen sich Verkehrsströme unterschiedlich markieren, etwa weil sie von unterschiedlichem Verkehrstyp (voice, video, data) sind, oder für unterschiedlich viel Geld zahlende Empfänger bestimmt sind, und daraufhin über eine dementsprechend unterschiedliche Verkehrswegestruktur routen.
- Die Erfindung bietet ferner die Möglichkeit, den Gesamtverkehr zu balancieren, indem bei Überlast Teile des Verkehrsaufkommen auf Ausweichverkehrswegestrukturen umgeleitet werden, oder aber, um Staus möglichst von vornherein zu vermeiden, Teile eines Verkehrsstromes wohlproportioniert über unterschiedliche Routen geleitet werden.
- Indem ein gewisser Verkehr in eine gewisse Verkehrswegestruktur gezwängt wird, kann zugleich eine andere Verkehrswegestruktur von diesem Verkehr freigehalten werden.
- Stets wird, trotz einer Vielzahl von eingerichteten Verkehrswegestrukturen, dafür gesorgt, daß alle IP-Pakete eines gewissen „IP micro flows" dieselbe Route nehmen, indem sie schlichtweg denselben DRCP im IP-Header führen.
- Nachfolgend werden mehrere erfindungsgemäße Verkehrswegestrukturen im Detail dargelegt. Zuvor sei aber darauf hingewiesen, daß auch dem heutigen IP-Routing, nämlich dem gemäß des Shortest-Path-Forwarding-Prinzips (SPF), eine gewisse Verkehrswegestruktur zugeordnet werden kann und daß die diesbezügliche (und zur Zeit einzige) Routingtabelle gleichfalls vermöge eines speziellen DRCP's zu selektieren ist.
- a) SPF
- Bei dem herkömmlichen SPF-Prinzip berechnet sich jeder Router einen Shortest-Path-Tree (SPT) mit sich als Wurzel hin zu allen übrigen Knoten des Netzes. Entsprechend dieses SPT's legt sich der jeweilige Router eine diesbezügliche Routingtabelle an, in die er bezüglich aller Erreichbarkeiten (Einzelzieladressen, Zieladressblöcke)speichert, welche der bei ihm anliegenden Leitungen für das Weiterleiten eines entsprechenden IP-Paketes zu verwenden sei. Diese herkömmliche Routingtabelle werde durch den speziellen DRCP="SPF" selektiert.
- b)SPF-x
- Als Variante zu a) kann jeder Router einen SPT derart berechnen, daß insgesamt nur Leitungen verwendet werden, welche einem gewissen (mit x bezeichneten) Satz an QoS-/Policy-/etc.-Zusatzanforderungen genügen. Eine Policy-Anforderung könnte sein „alles, nur keine Mautstraßen", oder „alles, nur nicht Mautstraßen oder Autobahnen", Oder aber „keine Leitung, welche dieser oder jener Verkehrswegestruktur bereits angehört".
- Für verschiedene solcher Sätze x möge der jeweilige Router eine eigene Routingtabelle anlegen und sie auf Grund spezieller DRCPs ="SPF-x" selektieren.
- C) SST
- Während in den obigen Fällen a) und b) in der Regel sämtliche Netzleitungen für die Übertragung herangezogen werden, ist dem nicht so in den Fällen c) und d).
- Jeder Router berechnet einen Smallest-Size-Tree (SST), d.h. einen (baumartigen sprich maschenlosen) Topologiegraphen von kleinster Größe, welcher sich zwischen allen Randpunkt-Routern eines Netzes erstreckt. Als Randpunkt-Router seien hierbei all jene Router eines Netzes verstanden, an denen entweder Teilnehmer (LANs, Hosts) und/oder Leitungsschnittstellen zu Nachbarnetzen hängen.
- Gibt es mehrere gleich-minimale SST-Topologien, sorgen sog.„tie-breaker"-Regeln dafür, daß jeder Netzknoten (gestützt auf identische Netztopologie-Kenntnisse und gestützt auf denselben Satz von Parametern und Parameterwerten) die identische SST-Topologie berechnet (typische tie-breaker-Regel: Wenn in einem Iterationsschritt irgendein Zwischenminimum bestimmt werden soll, es aber mehrere gleichwertige Möglichkeiten hierfür gibt, so wähle dasjenige wo der „beteiligte" Router die kleinere IP Adresse hat). Jeder Router komme somit zum identischen SST-Topologie-Ergebnis. Der jeweilige Router prüft, ob und ggf. wo er selbst in dieser SST-Topologie vorkommt und was seine dabei angrenzenden Leitungen sind.
- Er erstellt eine SST-bezügliche Routing Tabelle, d.h. er erstellt bzgl. aller Ziel-Randpunkt-Router und der dahinter sich befindlichen Erreichbarkeiten entsprechende „next hop Zink"-Einträge. Ferner trage er Sorge, daß diese Routing Tabelle vermöge des wohlbestimmten DRCP = "SST" selektiert wird. Man beachte, daß jede Kante des SST-Topologiegraphen bidirektional genutzt wird.
- d) SST-x
- Wie unter c) bestimme jeder Router den stets gleichen SST-Topologiegraphen, jedoch derart, daß dessen Kanten stets einem mit x bezeichneten Satz an QoS-/Bandbreiten-/Policy/etc.-Zusatzanforderungen genügen. Davon ausgehend, erstellt er eine spezielle Routingtabelle, welche durch den speziellen DRCP="SST-x" selektiert werde.
- Auch hier könnten Policy-Anforderung so lauten wie unter b) ausgeführt.
- Bezüglich der Bandbreiten-Zusatzanforderung sei angemerkt: Wenn man eine gewisse Bandbreite für die Kanten des SST-xi Topologiegraphen anfordert, so müssen, vermöge des Berechnungsalgorithmus, jene Netzkanten gemieden werden, welche bereits in früher bestimmten SST-xk Topologiegraphen vorkommen und hierbei in Summe entsprechend viel Bandbreitenzuteilung erfahren haben.
- e) „Überlauf-SST-x"
- Bezüglich einer SST-x Verkehrswegestruktur, siehe d), kann man gewisse Teilstrukturen identifizieren (etwa alle Kanten, die mindestens m Start/Ziel-Randknoten-Kombinationen bei der Übertragung dienlich sind). Man ordne diesen Kanten je ein „Disregard"-Bit und berechne den SST-x Baum erneut.
- Das Resultat ist wieder ein Smallest-Size-Tree Topologiegraph, bei dem alle Kanten abermals den vorgegebenen Randbedingungen x genügen, wo aber keine der mit Disregard markierten Kanten vorkommt.
- Ein Knoten, der in dieser „Überlauf-SST-x" Verkehrswegestruktur vorkommt, legt sich eine diesbezügliche Routing Tabelle an und macht sie selektierbar vermöge des DRCP= "Überlauf SST-x".
- Die Netzknoten des SST-x Topologiegraphen am Rande der mit Disregard behafteten Verkehrswege-Teilstrukturen werden, abhängig von lokal verfügbaren und aktuellen Netzlast-Indikatoren, ggf. die mit DiffRout-Codepoint „SST-x" ankommenden Pakete mit dem geänderten Diffrout-Codepoint „Überlauf-SST-x" weiterleiten und zwar gemäß der anliegenden Leitungen des Überlaufbaumes „Überlauf-SST-x" statt gemäß der anliegenden Leitungen des „SST-x" Topologiegraphen.
- f) „SPF-x, y-beste Route"
- Jeder Netzknoten bestimmt die zweitbeste/drittbeste /viertbeste Route hin zu allen Netzknoten, welche etwa dadurch bestimmt werden, daß man die zuvor berechneten, besseren Routen ausschließt (DISREGARD-Bits setzen!), und zwar mit sich selbst als Wurzelknoten und unter Berücksichtigung aller Randbedingungen x.
- Der jeweilige Netzknoten liegt hierzu eine eigene Routing-Tabelle an und macht diese selektierbar vermöge des DRCP= „SPF-x,y-beste Route".
- Man kann somit, etwa um den gesamten Verkehr zu balancieren, gezielt alternative Wege einschlagen, zugleich aber dafür sorgen, daß alle Pakete eines bestimmten IP-micro flows den identischen Weg durch das Netz nehmen (dies ist wichtig um Paketüberholungen zu vermeiden, sprich um die Fähigkeit des TCPs nämlich für die richtige Aneinanderreihung zu sorgen, nicht über Gebühr zu strapazieren). Noch wichtiger ist diese Fähigkeit für „TDM over IP"-Applikationen, wie z. B. Sprache über Internet VoIP (Voice over Internet Protocol).
Claims (8)
- Verfahren zur Weiterleitung von IP-Paketen in einem verbindungslosen Kommunikationsnetz, das mit einer Mehrzahl von Netzknoten gebildet ist, bei dem eine im Header eines IP-Paketes enthaltene Kennung beim jeweiligen Transit-Router eine diesbezüglich speziell angelegte Routingtabelle selektiert, um aus ihr die geeignete Leitung für das Weiterleiten des IP-Pakets zu ermitteln.
- Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Kennung mit den DSCP-Bits im Header eines IP-Paketes gebildet wird.
- Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die Kennung aus irgendwelchen Komponenten im IP-Header abgeleitet werden kann, etwa aus den Komponenten Protocol Type, DSCP-Bits, CU-Bits, sowie Flow Label (falls IPv6).
- Verfahren nach einem der vorstehenden Ansprüche dadurch gekennzeichnet, dass die selektierte Routingtabelle anhand eines Smallest-Size-Tree (SST) Topologiegraphen erstellt wurde, welcher sich, bidirektional zwischen den Randpunkt-Routern, sprich den Routern mit lokal angeschlossenen LANs, Hosts oder externen Leitungen, erstreckt, und dessen topologische Gestalt von all den darin vorkommenden Routern absolut gleich erkannt wird.
- Verfahren nach Anspruch 4 dadurch gekennzeichnet, dass bei der Bestimmung des SST-Topologiegraphen weitere Randbedingungen in Form von QoS-/Bandbreiten-/Policy-Anforderungen berücksichtigt werden.
- Verfahren nach Anspruch 1 dadurch gekennzeichnet, dass die selektierte Routingtabelle vom jeweiligen Router anhand der Ergebnisse einer Shortest-Path-Tree-Berechnung mit sich als Baumwurzelknoten und unter Berücksichtigung weiterer Randbedingungen in Form von QoS-/Policy-Anforderungen erstellt wird.
- Verfahren nach Anspruch 5 dadurch gekennzeichnet, dass die selektierte Routingtabelle einer Verkehrswegestruktur genügt, welche ganz oder zu Teilen gegenüber einer anderen, zuvor ermittelten Verkehrswegestruktur eine Überlauf-Verkehrswegestruktur darstellt, und bei dem gewisse Knoten aufgrund von lokal verfügbarer, aktueller Verkehrslastinformation, die empfangene Kennung abändern, nämlich passend zur diesbezüglichen Überlaufverkehrswege-struktur, und das IP Pakete dementsprechend weiterleiten.
- Verfahren nach Anspruch 5 oder 6 dadurch gekennzeichnet, dass die selektierte Routingtabelle im Vergleich zu einer anderen, zuvor bestimmten Routingtabelle die zweitbesten bzw. drittbesten, usw. Routen berücksichtigt, um damit das Balancieren des Gesamtverkehrs derart zu unterstützen, daß Verkehrsstaus möglichst gar nicht erst entstehen.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE2002132945 DE10232945A1 (de) | 2002-07-19 | 2002-07-19 | Differentiated Routing-Auswahl einer von mehreren Routingtabellen mittels Codepoint im IP-Header |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE2002132945 DE10232945A1 (de) | 2002-07-19 | 2002-07-19 | Differentiated Routing-Auswahl einer von mehreren Routingtabellen mittels Codepoint im IP-Header |
Publications (1)
Publication Number | Publication Date |
---|---|
DE10232945A1 true DE10232945A1 (de) | 2004-01-29 |
Family
ID=29796472
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE2002132945 Withdrawn DE10232945A1 (de) | 2002-07-19 | 2002-07-19 | Differentiated Routing-Auswahl einer von mehreren Routingtabellen mittels Codepoint im IP-Header |
Country Status (1)
Country | Link |
---|---|
DE (1) | DE10232945A1 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013142282A1 (en) * | 2012-03-20 | 2013-09-26 | Raytheon Company | Routing a data packet in a communication network |
US9537789B2 (en) | 2014-10-31 | 2017-01-03 | Raytheon Company | Resource allocating in a network |
-
2002
- 2002-07-19 DE DE2002132945 patent/DE10232945A1/de not_active Withdrawn
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013142282A1 (en) * | 2012-03-20 | 2013-09-26 | Raytheon Company | Routing a data packet in a communication network |
US10333839B2 (en) | 2012-03-20 | 2019-06-25 | Raytheon Company | Routing a data packet in a communication network |
US9537789B2 (en) | 2014-10-31 | 2017-01-03 | Raytheon Company | Resource allocating in a network |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE60214667T2 (de) | Wegbestimmung in einem datennetzwerk | |
DE102007022704B4 (de) | Verfahren zum Einrichten eines logischen Verbindungspfads in einem verbindungsorientierten paketvermittelten Kommunikationsnetzwerk | |
EP1593241B1 (de) | Zugangskontrolle für ein paketorientiertes netz unter berücksichtigung von resilience anforderungen | |
DE60128733T2 (de) | Regelbasiertes weitersenden in OSPF Netzwerken | |
DE60102367T2 (de) | Netzoptimierungsmethode | |
DE602004006333T2 (de) | Verfahren zur kontrollieren Qos in IP-Netzen | |
EP1430665A2 (de) | Verfahren und vorrichtung zur anpassung von label-switched-pfaden in paketnetzen | |
EP1428361B1 (de) | Verkehrsbegrenzung mittels zulässigkeitsprüfung für ein paketorientiertes verbindungsloses netz mit qos niveau übertragung | |
EP1629642B1 (de) | Verfahren für eine Verkehrsverteilung mittels Hash-Codes entsprechend einer Soll-Verkehrsverteilung in einem paketorientierten Netz mit Mehrwege-Routing | |
EP2638672A1 (de) | Verfahren zum erhöhen der qualität der datenübertragung in einem paketbasierten kommunikationsnetz | |
WO2005074196A1 (de) | Verfahren zur anpassung der link-gewichte im hinblick auf eine optimierte verkehrsverteilung | |
WO2004019565A1 (de) | Effizientes intra-domain routing in paketnetzen | |
EP2775677B1 (de) | Verfahren zur Übertragung von Datenpaketen in einem Datennetz aus einer Vielzahl von Netzknoten | |
EP1119216A1 (de) | Verfahren und Vorrichtung zur Zugangssteuerung eines Kommunikationsnetzes | |
DE10232945A1 (de) | Differentiated Routing-Auswahl einer von mehreren Routingtabellen mittels Codepoint im IP-Header | |
DE602006000136T2 (de) | Vorreservierung von Ressourcen für Verbindungswege in einem Kommunikationsnetz an Kommunikation von Anschriften von Päckchen oder von Etiketten | |
DE10232944B4 (de) | IP Paket-Weiterleitung gestützt auf signalisiertem Routingprinzip | |
WO2005125117A1 (de) | Verfahren zur ressourcen-reservierung für ein inter-domain-routing mit dienstgütemerkmalen | |
WO2005004412A1 (de) | Versand von ip-datenpaketen über signatur-schalt-pfade | |
DE10328620B4 (de) | Verfahren und Netzknoten zur Wegesuche in einem paketvermittelnden Kommunikationsnetz | |
DE10324370A1 (de) | Netzknoten eines paketvermittelnden Kommunikationsnetzes und Verfahren zur Verkehrsverteilung von Datenverkehr in einem paketvermittelnden Kommunikationsnetz | |
DE10340809A1 (de) | Optimierung der Routenbestimmung in einem Netz mit Mehrwege-Routing | |
WO2002078387A1 (de) | Verfahren und system zum effizienten verwalten von ressourcen in mpls netzwerken | |
DE10246109A1 (de) | Effizientes Label Binding für das Routing von Datenpaketen mittels Labels | |
WO2005101754A1 (de) | Netz-ausgangs-bezogenes policing |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8127 | New person/name/address of the applicant |
Owner name: NOKIA SIEMENS NETWORKS GMBH & CO.KG, 81541 MUE, DE |
|
8141 | Disposal/no request for examination |