WO2004107675A2 - Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz - Google Patents

Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz Download PDF

Info

Publication number
WO2004107675A2
WO2004107675A2 PCT/EP2004/050950 EP2004050950W WO2004107675A2 WO 2004107675 A2 WO2004107675 A2 WO 2004107675A2 EP 2004050950 W EP2004050950 W EP 2004050950W WO 2004107675 A2 WO2004107675 A2 WO 2004107675A2
Authority
WO
WIPO (PCT)
Prior art keywords
network node
packet
control component
packets
interface
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.)
Ceased
Application number
PCT/EP2004/050950
Other languages
English (en)
French (fr)
Other versions
WO2004107675A3 (de
Inventor
Johannes Bergmann
Anton Schmitt
Christian Winkler
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
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
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, Siemens Corp filed Critical Siemens AG
Priority to US10/558,901 priority Critical patent/US20060268911A1/en
Priority to EP04741669A priority patent/EP1629641A2/de
Publication of WO2004107675A2 publication Critical patent/WO2004107675A2/de
Publication of WO2004107675A3 publication Critical patent/WO2004107675A3/de
Anticipated expiration legal-status Critical
Priority to US12/352,013 priority patent/US20090180485A1/en
Ceased legal-status Critical Current

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
    • H04L45/00—Routing or path finding of packets in data switching 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/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2408—Traffic characterised by specific attributes, e.g. priority or QoS for supporting different services, e.g. a differentiated services [DiffServ] type of service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2458—Modification of priorities while in transit
    • 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]

Definitions

  • the invention relates to a method according to the preambles of claims 1, 3, 5 and 7.
  • IP networks will transport higher-quality services and allow new applications in addition to the Internet and best-effort services that are common today.
  • network nodes and / or network elements such as routers, or
  • control components as external servers to the network components, network nodes or routers to be controlled. This can be done directly, i.e. by a connection or line between an external interface of the network component and the control component located nearby, or via a network connection between the network component and control component.
  • the first integrated solution has the advantage that the control component is provided with internal information of the network component due to the close coupling to the network component.
  • a "provided” solution is manufacturer-independent and more flexible, since it is not so closely interwoven with the internals of the network component.
  • “provided” solutions can be based on standardized hardware, short HW, and software, short SW, solutions Network components such as routers are mostly based on proprietary HW / SW solutions. Shorter development cycles and cost savings can be achieved through “provided” control components.
  • the disadvantage of "provided” solutions is that internal information of the network component is not available.
  • One task of an admission control is to accept incoming resource requests, compare them with the resources still available and, if resources are still available, a network node or router, e.g. to program the router on the edge of the network or edge router to control the data flow. This includes the setting of so-called functions such as marking, filtering and policing.
  • RSVP resource reservation protocol
  • RSVP-capable network i.e. of a network with RSVP-capable network nodes or routers according to FIG. 1, the sequence is to be described schematically.
  • FIG. 1 shows a schematic IP network, consisting of several network nodes or routers A to H, each of which internally has a control component AC.
  • the network node A is connected to the network node E on the one hand by a series connection of the network nodes B, C, D and on the other hand by a series connection of the network nodes F, G, H.
  • the network nodes B and G, C and H and D and H are also connected to one another.
  • connections or connection paths are designed, for example, as electrical or optical lines, such as two-wire lines, coaxial cables or optical fibers.
  • a node X is connected to network node A and a node Y is connected to network node E.
  • Subscriber X creates a resource request to the network for a data stream to subscriber Y. It must be ensured that the resource reservations in the network nodes are actually made along the later data path. In IP networks, this data path depends on the current routing. Therefore in the resource reservation Protocol RSVP sent the resource request with the IP destination address, i.e. the IP address of subscriber Y, into the network. It thus automatically follows the data path of the later data stream to subscriber Y. Although these RSVP messages are not now addressed to the RSVP control components AC or RSVP instances, the RSVP control components AC or RSVP instances must be on the way lying network nodes each get knowledge of it.
  • Protocol type "RSVP" in the IP header ie in the header of an IP packet, specially marked.
  • the routers recognize this type of protocol and forward messages marked in this way directly to their RSVP instance, that is to say to the control component AC.
  • the RSVP instance on the network edge to subscriber X must configure "its" edge router A (filtering, marking, policing). Specifically, the interface must be configured via which the RSVP message from node X originally arrived and via which the data stream from node X to node Y will arrive later. Since the RSVP instance is implemented in the router, it can query this internal information.
  • the solution for the two points A and B lies in the close internal coupling between the network node and the control component.
  • the resource requests reach the control component via special filters in the network node or router, which recognize the protocol ID and forward the packets past the routing directly to the internal control component.
  • the control component AC receives information on the configuration of the network node or router by accessing router-internal data.
  • the problem with external control components is that this internal information is not queried from the network node or made available by the network node.
  • the object of the present invention is to provide a method in which received IP packets with interface information of the receiving network node can be passed on to an external control component.
  • the advantage of the invention is that IP packets with control information internal to the node are forwarded to an external control component.
  • a control component "provided" to a network node can take on more extensive control tasks of the network node.
  • the external control component can be arranged at a remote point in the network and is connected via a network connection.
  • FIG. 1 shows a schematic IP network with internal control components AC according to the prior art.
  • 2 shows an IP network constructed analogously to FIG. 1 with two external control components AC according to the invention.
  • FIG. 1 shows an IP network according to the prior art, already explained in the introduction to the description.
  • FIG. 2 shows a network according to FIG. 1, with the difference that an external control component AC is connected to network elements D and G in each case.
  • IP packets are to be transmitted from subscriber X to subscriber Y.
  • the external control components AC require certain IP packets, such as in-band IP signaling packets, for example RSVP packets, and the information at which interface of the network node the IP packet / in-band IP signaling packet / RSVP packet was received , The latter information is only available internally in the network node and cannot be queried.
  • the routing tables of the network node or router only contain information about destinations, but not about where a packet came from.
  • rules are configured on the interfaces of the network nodes.
  • Current network nodes or routers support so-called policy routing. Rules can be configured for how to deal with special packages. So-called tunneling is also used.
  • IP tunnels eg GRE tunnels
  • the original IP packet at the tunnel entrance is supplemented by a tunnel header including a tunnel ID and a new outer IP header.
  • the IP packet is routed through the network.
  • the outer header is removed and the original package is processed further.
  • Modern network nodes or routers, in particular the edge routers affected here, often support one or more variants of tunneling.
  • tunnel start the network node or router
  • end point the control component AC or control entity
  • a first variant is based on using the tunnel ID for the transmission of internal information.
  • a separate tunnel to the control component is set up for each interface of the network node, so that the interface number corresponds explicitly or implicitly to the tunnel ID.
  • a tunnel to the control component is set up from each interface of the network node.
  • a rule is set up in the network node or on the interface that certain IP packets, such as in-band IP signaling packets, which are identified by an entry in the protocol field of the IP header of the IP packet, are "outer" "IP packet are packed, the IP address of the control component assigned to the network node is entered as the destination IP address in the" outer "IP packet and a unique value assigned to the interface, which differs from the values of the other interfaces of the network node distinguishes and with which the interface can be clearly identified, entered as tunnel ID in the "outer” IP packet.
  • This packet is forwarded to the control component through IP routing.
  • in-band IP signaling packets of the "RSVP" type are packed and transmitted.
  • This tunnel solution has the advantage that the control components or control instances do not have to be connected directly to the network node or router, but can be placed anywhere in the network, as in FIG. 2 exemplified by the control components AC on the network nodes D and G. The control components AC can then be reached via the logical "direct interface" tunnel.
  • a solution by so-called DSCP marking is proposed for a similar task.
  • a specific received IP packet such as an in-band IP signaling packet of the “RSVP” type
  • the value of a specific field such as the DSCP field
  • the IP header or header field of the IP packet is changed and one of depending on the receiving interface of the network node in the specific header field / DSCP field.
  • This solution can be combined with the tunnel solution.Tunnels can be set up and the DSCP fields of an IP packet can also be modified.
  • the rules on the interfaces of the network nodes then contain a corresponding marking, such as DSCP marking, and the corresponding tunnel as a "next-hop" entry.
  • the DSCP field is assumed to be the field to be changed, but another field can also be used in the header or header of the IP packet.
  • a DSCP field change or a DSCP marking should be carried out on the inner IP header.
  • the outer IP header can then really be used for DSCP priority identification.
  • tunnel ID no longer has to contain a value assigned to the interface, since this is clearly entered in the DSCP field.
  • a tunnel to the assigned control component does not have to be set up from every interface of the network node become.
  • at least one tunnel to the control component could be set up from the network node, all IP packets of a certain type, such as in-band IP signaling packets, for example “RSVP” packets, being transmitted to the control component and the distinction at which interface the packet was received through the changed DSCP field.
  • IP packets of a certain type such as in-band IP signaling packets, for example “RSVP” packets
  • the DSCP field is 6 bits in size, which allows a range of 64 values, a combination of tunneling and DSCP marking increases the available range of values. This means that a large area can be covered with just a few tunnels. By e.g. 2 tunnels and DSCP marking can be used to differentiate between 128 values or interfaces of the network node.
  • Tunneling can also be achieved using Multi Protocol Label Switching, MPLS for short.
  • MPLS Multi Protocol Label Switching
  • the process works analogously to IP tunnels, with the difference that MPLS "tunnels" or MPLS paths are used instead of the IP tunnels.
  • Multiprotocol Label Switching maintains network-wide states that define the paths or paths on which packets are routed through the network bypassing "normal" IP routing.
  • the network nodes no longer forward packets based on the destination IP addresses, but a bit sequence, a so-called label, is added to each packet at the network input.
  • This label which is evaluated in each network node, determines the way in which the packets are forwarded.
  • the connection between labels and paths must be established when the network is started up.
  • the label is removed at the network outlet.
  • local or local mechanisms or rules are required in order to redirect packets to a replacement path if the originally intended path fails or to set up a replacement path after a failure.
  • An in-band IP signaling packet received at an interface of the network node or an IP packet of the “RSVP” type, or also of another type, is recognized and the packet is preceded by an MPLS label, the label ID of which is unambiguously the receiving one
  • the interface assigned and leads to the control component assigned to the network node The IP packet packed in this way is forwarded to the control component by means of MPLS.
  • the MPLS label ID preceding the IP packet is evaluated in the control component and a comparison with stored values is used in the Control component determines the interface or the interface on which the IP packet was received by the network node.
  • the rule is implemented on the interface of the network node that a certain value, defined for the interface, is placed in front of the IP packet as an MPLS label and the packet is forwarded by MPLS.
  • the MPLS process must ensure that packets with a specific MPLS label ID lead to the corresponding destinations, in the example to the control component.
  • MPLS can be combined with DSCP marking, analogous to the previously written procedure. It is sufficient if at least one MPLS label ID is entered in the network node, since the interfaces of the network node are differentiated by DSCP marking.
  • an in-band IP signaling packet or a packet of the "RSVP" type received at an interface of the network node is recognized and processed in such a way that the value of a specific field, such as the "DSCP" field, depends on the receiving interface is changed.
  • a unique interface ID that differs from the interface ID of the other interfaces of the
  • Network node differentiates, entered in the DSCP field, also prepended the IP packet with an MPLS label and ver changed packet forwarded to the engine by the MPLS process. Not every interface has to enter its own MPLS label ID, since the DSCP field differentiates between the interfaces. Large ranges of values can also be achieved by combining the MPLS label ID and DSCP marking. 128 MPLS label ID and DSCP marking can be used to distinguish 128 values or interfaces of a network node.

Landscapes

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

Abstract

Beim Verfahren werden IP-Pakete an Schnittstellen eines Netzknoten empfangen, erkannt, ausgewertet und verarbeitet. Ein IP-Tunnel wird von jeder Schnittstelle des Netzknotens zur Steuerkomponente eingerichtet. Ein an einer Schnittstelle des Netzknotens empfangenes In-Band IP Signalisierungspaket, das durch einen Eintrag im Protokollfeld des Kopffeldes des IP-Paketes gekennzeichnet ist, wird durch den IP-Tunnel zur Steuerkomponente weitergeleitet.

Description

Beschreibung
Verfahren zur Weitergabe von IP-Paketen an eine externe Steuerkomponente eines Netzknotens in einem mehrere Netzknoten aufweisenden IP-Pakete vermittelnden Kommunikationsnetz.
Die Erfindung betrifft ein Verfahren nach den Oberbegriffen der Ansprüche 1, 3, 5 und 7.
Zukünftig werden Internet-Protokoll-Netze, kurz IP-Netze, neben den heute üblichen Internet- und Best-effort-Diensten auch höherwertige Qualitätsdienste transportieren und neue Anwendungen erlauben. Dazu sind Erweiterungen der Steuerung der Netzknoten eines IP-Netzes bzw. der Netzsteuerung nötig, z.B. zur Verwaltung der Netzressourcen oder für schnelle Re- konfigurationen im Fehlerfall.
Generell gibt es die Alternativen:
• Steuerkomponenten in die Netzkomponenten, Netzknoten und/oder Netzelemente, wie Router, zu integrieren oder
• Steuerkomponenten als externe Server an die zu steuernden Netzkomponenten, Netzknoten bzw. Router anzubinden. Dies kann direkt, d.h. durch eine Verbindung oder Leitung zwischen einer externen Schnittstelle der Netzkomponente und der in der Nähe befindlichen Steuerkomponente, oder über eine Netzverbindung zwischen Netzkomponente und Steuerkomponente erfolgen.
Die erste integrierte Lösung hat den Vorteil, dass der Steu- erkomponente durch die enge Kopplung zur Netzkomponente interne Informationen der Netzkomponente zur Verfügung stehen.
Demgegenüber ist eine "beigestellte" Lösung herstellerunabhängig und flexibler, da sie gerade nicht so eng mit den Interna der Netzkomponente verwoben ist. Darüber hinaus können "beigestellte" Lösungen auf standardisierten Hardware-, kurz HW, und Software-, kurz SW, Lösungen basieren, während Netzkomponenten, wie Router, meist auf proprietären HW/SW- Lösungen basieren. Durch "beigestellte" Steuerkomponenten lassen sich kürzere Entwicklungszyklen und Kosteneinsparungen erreichen. Der Nachteil "beigestellter" Lösungen besteht dar- in, dass interne Informationen der Netzkomponente nicht zur Verfügung stehen.
Am Beispiel einer Ad ission Control-, kurz AC, Steuerkomponente soll im folgenden die Problematik der zweiten, exter- nen, "beigestellten" Server-Lösung dargestellt werden.
Eine Aufgabe einer Admission Control besteht darin, ankommende Ressourcen Anfragen entgegenzunehmen, diese mit den noch verfügbaren Ressourcen abzugleichen und bei noch verfügbaren Ressourcen einen Netzknoten bzw. Router, z.B. den Router am Netzrand respektive Edge-Router für die Kontrolle des Datenflusses zu programmieren. Dies umfasst die Einstellung von sogenannten Funktionen, wie marking, filtering und policing.
Dabei treten u.a. die folgenden zwei Fragestellungen auf:
A) Wie erreichen die Ressourcen-Anfragen die beigestellte Steuerungskomponente bzw. Admission Control?
B) Wie kann die Steuerungskomponente bzw. Admission Control den Netzknoten steuern und konfigurieren und woher bezieht die Steuerungskomponente die nötigen Informationen über die Interna der Netzkomponente, z.B. an welchem Interface ist ein Paket empfangen worden und welches Interface ist zu konfigurieren?
Zu A) existieren im Prinzip zwei Lösungsvarianten:
1) Der Datenpfad, den die IP Pakete nehmen, ist bekannt und entsprechend kann die Steuerungskomponente bzw. Admission Control direkt adressiert werden. Dies wird als sogenannte Out-Band Signalisierung bezeichnet.
2) Das Signalisierungsprotokoll folgt dem Pfad der Datenpakete und findet so die Steuerungskomponente bzw. Admission Control automatisch. Dies wird als sogenannte In-Band Signalisierung bezeichnet.
Im folgenden wird ausschließlich von der Signalisierung nach Variante 2) ausgegangen, also der In-Band Signalisierung.
Das standardisierte Ressourcen Reservierungs-Protokoll RSVP ist ein In-Band Signalisierungsprotokoll. Es löst die oben aufgezeigte Fragestellungen wie unter Punkt 2) beschrieben und führt eine Hop-by-Hop Reservierung im Netzknoten durch. Kernpunkt dabei ist, dass die RSVP-Instanz im Router selbst implementiert wird und daher sehr eng mit dem Router und seinen Interna verzahnt operieren kann.
Am Beispiel eines RSVP-fähigen Netzes, d.h. eines Netzes mit RSVP-fähigen Netzknoten bzw. Routern gemäß Figur 1 soll schematisch der Ablauf beschrieben werden.
Figur 1 zeigt ein schematisches IP Netz, bestehend aus mehre- ren Netzknoten bzw. Routern A bis H, die intern jeweils eine Steuerkomponente AC aufweisen. Der Netzknoten A ist einerseits durch eine Serienschaltung der Netzknoten B, C, D und andererseits durch eine Serienschaltung der Netzknoten F, G, H mit dem Netzknoten E verbunden. Die Netzknoten B und G, C und H sowie D und H sind ebenfalls untereinander verbunden.
Die Verbindungen bzw. Verbindungswege sind bspw. als elektrische oder optische Leitungen ausgeführt, wie Zweidrahtleitungen, Koaxialkabel oder Lichtwellenleiter. Am Netzknoten A ist ein Teilnehmer X angeschlossen und am Netzknoten E ist ein Teilnehmer Y angeschlossen.
Der Teilnehmer X erzeugt eine Ressourcen-Anforderung an das Netz für einen Datenstrom zu Teilnehmer Y. Dabei muss sichergestellt werden, dass die Ressourcen-Reservierungen in den Netzknoten auch tatsächlich entlang des späteren Datenpfades vorgenommen werden. In IP-Netzen hängt dieser Datenpfad vom aktuellen Routing ab. Daher wird im Ressourcen Reservierungs- Protokoll RSVP die Ressourcen-Anforderung mit der IP Zieladresse, also der IP-Adresse des Teilnehmers Y, in das Netz gesendet. Sie folgt damit automatisch dem Datenpfad des späteren Datenstroms zu Teilnehmer Y. Obwohl diese RSVP- Nachrichten ja nun nicht an die RSVP-Steuerungskomponenten AC bzw. RSVP-Instanzen adressiert sind, müssen die RSVP- Steuerungskomponenten AC bzw. RSVP-Instanzen der auf dem Weg liegenden Netzknoten jeweils Kenntnis davon erhalten.
Daher sind diese Nachrichten durch den definierten IP-
Protokoll-Typ "RSVP" im IP Header, also im Kopf eines IP- Paketes, speziell gekennzeichnet.
Die Router erkennen diesen Protokolltyp und geben solcherma- ßen gekennzeichnete Nachrichten direkt an ihre RSVP-Instanz weiter, also an die Steuerkomponente AC.
Später, im Verlauf der Prozedur, muss die RSVP-Instanz am Netzrand zum Teilnehmer X "ihren" Edge-Router A konfigurieren (filtering, marking, policing) . Konkret ist dasjenige Interface zu konfigurieren, über das die RSVP-Nachricht vom Teilnehmer X ursprünglich eingetroffen war und über das später der Datenstrom von Teilnehmer X zu Teilnehmer Y eintreffen wird. Da die RSVP-Instanz im Router implementiert ist, kann sie diese internen Informationen abfragen.
Die Lösung für die beiden Punkte A und B liegt hier in der engen internen Kopplung zwischen Netzknoten und Steuerkomponente. Zu A) Die Ressourcen-Anfragen erreichen die Steuerkomponente über spezielle Filter im Netzknoten bzw. Router, welche die Protokoll-ID erkennen und die Pakete am Routing vorbei direkt an die interne Steuerkomponente weiterleiten. Zu B) Information zur Konfiguration des Netzknotens bzw. Routers erhält die Steuerungskomponente AC durch Zugriff auf routerinterne Daten. Bei externen Steuerungskomponenten besteht das Problem, dass diese internen Informationen nicht beim Netzknoten abgefragt bzw. vom Netzknoten zur Verfügung gestellt werden. Ein weite- res Problem existiert, wenn die externen Steuerungskomponenten des Netzknotens nicht direkt diesem beigestellt sind, sondern sich an einer weit entfernten Stelle des Netzes befinden und nur über eine Netzwerkverbindung erreichbar sind.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren anzugeben, bei dem empfangene IP-Pakete mit Interface Informationen des empfangenden Netzknoten an eine externe Steuerkomponente weitergegeben werden können.
Diese Aufgabe wird durch Verfahren gemäß den Merkmalen der Ansprüche 1, 3, 5 oder 7 gelöst.
Der Vorteil der Erfindung besteht darin, dass IP Pakete mit netzknoteninternen Steuerinformationen an eine externe Steue- rungskomponente weitergeleitet werden. Dadurch kann eine einem Netzknoten "beigestellte" Steuerungskomponente umfangreichere Steuerungsaufgaben des Netzknotens übernehmen. Ein weiterer Vorteil besteht darin, dass die externe Steuerungskomponente an einer entfernten Stelle des Netzes ange- ordnet sein kann und über eine Netzwerkverbindung angeschlossen ist.
Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben .
Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im folgenden erläutert.
Dabei zeigt:
Figur 1 ein schematisches IP-Netz mit netzknoteninternen Steuerkomponenten AC gemäß dem Stand der Technik. Figur 2 ein gemäß Figur 1 analog aufgebautes IP- Netz mit zwei externen Steuerkomponenten AC gemäß der Erfindung.
Die Figur 1 zeigt ein bereits in der Beschreibungseinleitung erläutertes IP-Netz gemäß dem Stand der Technik.
Die Figur 2 zeigt ein Netz gemäß Figur 1, mit dem Unter- schied, dass jeweils eine externe Steuerungskomponente AC an den Netzelementen D und G angeschlossen ist.
Analog dem in der Beschreibungseinleitung genannten Beispiel sollen Datenpakete vom Teilnehmer X zum Teilnehmer Y übertra- gen werden. Dabei benötigen die externen Steuerungskomponenten AC bestimmte IP-Pakete, wie In-Band IP Signalisierungspa- kete, beispielsweise RSVP-Pakete, und die Information, an welchem Interface des Netzknotens das IP-Paket / In-Band IP Signalisierungspaket / RSVP-Paket empfangen wurde. Letztere Information ist nur intern im Netzknoten verfügbar und kann nicht abgefragt werden. Die Routingtabellen des Netzknotens bzw. Routers enthalten nur Informationen über Ziele, jedoch nicht darüber, woher ein Paket kam.
Um das Problem zu lösen werden auf den Interfaces der Netzknoten Regeln konfiguriert. Aktuelle Netzknoten bzw. Router unterstützen sogenanntes Policy-Routing. Dabei können Regeln konfiguriert werden, wie mit speziellen Paketen zu verfahren ist. Zudem wird das sogenannte Tunneling verwendet.
Durch IP-Tunnel, z.B. GRE-Tunnel, wird das originale IP Paket am Tunneleingang um einen Tunnelheader inklusive einer Tun- nel-ID und einem neuen äußeren IP Header ergänzt. Mit diesem IP-Header wird das IP-Paket durch das Netz gerouted. Am Tun- nelendpunkt wird der äußere Header wieder entfernt und das Original-Paket weiter bearbeitet. Moderne Netzknoten bzw. Router, insbesondere die hier betroffenen Edge Router, unterstützen oftmals eine oder mehrere Varianten des Tunneling.
Die Lösung mit Tunneln beruht darauf, dass mehrere Tunnels vom Netzknoten bzw. Router (Tunnelbeginn) zu der Steuerungskomponente AC bzw. Steuerinstanz (Endpunkt) eingerichtet werden, die durch ihre Tunnel-Identifikationsnummer, kurz Tun- nel-ID, im Tunnel-Header unterschieden werden.
Eine erste Variante beruht darauf, die Tunnel-ID zur Übertragung interner Information zu verwenden. So wird pro Interface des Netzknotens ein eigener Tunnel zur Steuerungskomponente eingerichtet, so dass die Interface-Nummer explizit oder im- plizit der Tunnel-ID entspricht.
Hierzu wird von jeder Schnittstelle des Netzknotens ein Tunnel zur Steuerungskomponente eingerichtet. Dazu wird eine Regel im Netzknoten oder auf der Schnittstelle eingerichtet, dass bestimmte IP-Pakete, wie In-Band IP Signalisierungspake- te, die durch einen Eintrag im Protokollfeld des IP-Headers des IP-Paketes gekennzeichnet sind, in einem zweiten, "äußeren" IP-Paket eingepackt werden, die IP-Adresse der dem Netzknoten zugeordneten Steuerungskomponente als Ziel-IP-Adresse in das "äußere" IP-Paket eingetragen wird und ein dem Interface zugeordneter eindeutiger Wert, der sich von den Werten der anderen Interfaces des Netzknoten unterscheidet und mit dem das Interface eindeutig erkannt werden kann, als Tunnel- ID in das "äußere" IP-Paket eingetragen. Dieses Paket wird durch das IP-Routing an die Steuerungskomponente weitergeleitet. Analog werden In-Band IP Signalisierungspakete des Typs „RSVP" eingepackt und übertragen.
Durch diese Tunnel-Lösung entsteht der Vorteil, dass die Steuerungskomponenten bzw. Steuerinstanzen nicht direkt an den Netzknoten bzw. Router angebunden sein müssen, sondern irgendwo in das Netz gestellt werden können, wie in Figur 2 beispielhaft durch die Steuerungskomponenten AC an den Netzknoten D und G dargestellt. Die Steuerungskomponenten AC sind dann über die logische "Direkt-Schnittstelle" Tunnel erreichbar.
In einer parallelen Patentanmeldung der Anmelderin wird für eine ähnliche Aufgabe eine Lösung durch das sogenannte DSCP- Marking vorgeschlagen. Dabei wird bei einem bestimmten empfangenen IP-Paket, wie ein In-Band IP Signalisierungspaket des Typs „RSVP", der Wert eines bestimmten Feldes, wie des DSCP-Feldes, des IP-Headers bzw. Kopffeldes des IP-Paketes verändert und ein von der empfangenden Schnittstelle des Netzknotens abhängiger Wert in das bestimmte Kopffeld / DSCP- Feld eingetragen. Diese Lösung lässt sich mit der Tunnel- Lösung kombinieren . So können Tunnel eingerichtet werden und zusätzlich können die DSCP Felder eines IP-Paketes modifiziert werden.
Die Regeln auf den Interfaces der Netzknoten enthalten dann ein entsprechendes Marking, wie DSCP-Marking, und als "next- hop" Eintrag den entsprechenden Tunnel.
Im folgenden wird als zu veränderndes Feld das DSCP-Feld angenommen, es kann aber auch ein anderes Feld im Header bzw. Kopf des IP-Paketes verwendet werden.
Wird DSCP-Marking und Tunneling verwendet, sollte eine DSCP- Feld Veränderung bzw. ein DSCP-Marking auf dem inneren IP- Header vorgenommen werden. Der äußeren IP-Header kann dann wirklich zur DSCP Prioritätskennzeichnung verwendet werden.
Zudem muss die Tunnel-ID nicht mehr einen der Schnittstelle zugeordneten Wert enthalten, da dieser eindeutig in das DSCP- Feld eingetragen wird.
Außerdem muss nicht von jeder Schnittstelle des Netzknotens ein Tunnel zur zugeordneten Steuerungskomponente eingerichtet werden. So könnte vom Netzknoten mindestens ein Tunnel zur Steuerungskomponente eingerichtet werden, wobei alle IP- Pakete eines bestimmten Typs, wie In-Band IP Signalisierungs- pakete, z.B. „RSVP"-Pakete, zur Steuerungskomponente übertra- gen werden und die Unterscheidung, an welcher Schnittstelle das Paket empfangen wurde, durch das veränderte DSCP Feld erfolgt.
Da das DSCP Feld 6 Bit groß ist, was einen Bereich von 64 Werten erlaubt, wird durch eine Kombination von Tunneling und DSCP-Marking der verfügbare Wertebereich erhöht. Dadurch kann mit wenig Tunneln ein großer Bereich abgedeckt werden. Durch z.B. 2 Tunnel und DSCP-Marking lassen sich so 128 Werte bzw. Schnittstellen respektive Interfaces des Netzknotens unter- scheiden.
Ein Tunneling lässt sich ebenfalls durch Multi Protocol Label Switching, kurz MPLS, erreichen. Das Verfahren arbeitet analog zu IP-Tunneln, mit dem Unterschied, dass an Stelle der IP-Tunnel MPLS-"Tunnels" beziehungsweise MPLS-Pfade eingesetzt werden.
Beim Multiprotocol Label Switching, kurz MPLS, werden netzweit Zustände gehalten, welche die Wege bzw. Pfade definie- ren, auf denen Pakete unter Umgehung des "normalen" IP- Routing durch das Netz geleitet werden. Die Netzknoten leiten dabei Pakete nicht mehr anhand der Ziel-IP-Adressen weiter, sondern es wird jedem Paket am Netzeingang eine Bitfolge, ein sogenanntes Label, beigefügt. Dieses Label, das in jedem Netzknoten ausgewertet wird, bestimmt, auf welchem Weg die Pakete weitergeleitet werden. Der Zusammenhang zwischen Labels und Pfaden muss bei der Inbetriebnahme des Netzes hergestellt werden. Das Label wird am Netzausgang wieder entfernt. Außerdem werden örtlich bzw. lokal Mechanismen bzw. Regeln benötigt, um Pakete auf einen Ersatzpfad umzulenken, wenn der ursprünglich vorgesehene Pfad ausfällt, oder um einen Ersatzpfad nach einem Ausfall aufzubauen. Dabei wird ein an einer Schnittstelle des Netzknotens empfangenes In-Band IP Signalisierungspaket bzw. ein IP-Paket des Typs „RSVP", oder auch eines anderen Typs, erkannt und dem Paket ein MPLS-Label vorangestellt, dessen Label-ID ist eineindeutig der empfangenden Schnittstelle zugeordnet und führt zu der dem Netzknoten zugeordneten Steuerungskomponente. Das derart eingepackte IP-Paket wird mittels MPLS zur Steuerungskomponente weitergeleitet. Die dem IP-Paket vorangestellte MPLS-Label-ID wird in der Steuerungskomponente ausgewertet und aus einem Vergleich mit gespeicherten Werten wird in der Steuerungskomponente die Schnittstelle bzw. das Interface ermittelt, auf dem das IP-Paket vom Netzknoten empfangen wurde.
Auf dem Interface des Netzknotens wird die Regel implementiert, dass ein bestimmter, für das Interface fest definierter Wert als MPLS-Label dem IP-Paket vorangestellt wird und das Paket durch MPLS weitergeleitet wird. Durch das MPLS- Verfahren muss sichergestellt werden, dass Pakete mit einer bestimmten MPLS-Label-ID zu den entsprechenden Zielen führen, im Beispiel zur Steuerungskomponente.
Auch in diesem Fall kann MPLS mit DSCP-Marking, analog dem vorher geschriebenen Verfahren, kombiniert werden. Dabei reicht es, wenn im Netzknoten mindestens eine MPLS-Label-ID eingtragen wird, da die Unterscheidung der Schnittstellen des Netzknotens durch das DSCP-Marking erfolgt.
Beispielsweise wird ein an einer Schnittstelle des Netzkno- tens empfangenes In-Band IP Signalisierungspaket bzw. ein Paket des Typs "RSVP" erkannt und derart verarbeitet, dass der Wert eines bestimmten Feldes, wie des "DSCP" Feldes, in Abhängigkeit von der empfangenden Schnittstelle verändert wird. Zum Beispiel wird eine eindeutige Schnittstellen-ID, die sich von den Schnittstellen-ID der anderen Schnittstellen des
Netzknotens unterscheidet, in das DSCP-Feld eingetragen, ferner dem IP-Paket ein MPLS-Label vorangestellt und dieses ver änderte Paket durch das MPLS-Verfahren an die Steuerkomponente weitergeleitet. Hierbei muss nicht jede Schnittstelle eine eigene MPLS-Label-ID eintragen, da die Unterscheidung der Schnittstellen respektive Interfaces durch das DSCP-Feld erfolgt. Ebenso lassen sich durch Kombination von MPLS-Label-ID und dem DSCP-Marking große Wertebereiche erreichen. Durch z.B. 2 MPLS-Label-ID und DSCP-Marking lassen sich 128 Werte bzw. Schnittstellen eines Netzknotens unterscheiden.

Claims

Patentansprüche
1. Verfahren zur Weitergabe von Internet-Protokoll-Paketen respektive IP-Paketen an eine externe Steuerkomponente eines Netzknotens in einem mehrere Netzknoten aufweisenden IP- Pakete vermittelnden Kommunikationsnetz, bei dem IP-Pakete an Schnittstellen des Netzknoten empfangen, erkannt, ausgewertet und verarbeitet werden, d a d u r c h g e k e n n z e i c h n e t, dass ein IP-Tunnel von jeder Schnittstelle des Netzknotens zur Steuerkomponente eingerichtet wird und dass ein an einer Schnittstelle des Netzknotens empfangenes InBand IP Signalisierungspaket, das durch einen Eintrag im Protokollfeld des Kopffeldes des IP-Paketes gekennzeichnet ist, durch den IP-Tunnel zur Steuerkomponente weitergeleitet wird.
2. Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t, dass ein IP-Tunnel von jeder Schnittstelle des Netzknotens zur Steuerkomponente eingerichtet wird und dass ein an einer Schnittstelle des Netzknotens empfangenes IP Pa¬ ket des Typs "RSVP" durch den IP-Tunnel zur Steuerkomponente weitergeleitet wird.
3. Verfahren zur Weitergabe von Internet-Protokoll-Paketen respektive IP-Paketen an eine externe Steuerkomponente eines Netzknotens in einem mehrere Netzknoten aufweisenden IP- Pakete vermittelnden Ko munikationsnetz, bei dem IP-Pakete an Schnittstellen des Netzknoten empfangen, erkannt, ausgewertet und verarbeitet werden, d a d u r c h g e k e n n z e i c h n e t, dass mindestens ein IP-Tunnel vom Netzknoten zur Steuerkomponente eingerichtet wird und dass bei einem an einer Schnittstelle des Netzknotens empfangenen und erkannten In-Band IP Signalisierungspaket, das durch einen Eintrag im Protokollfeld des Kopffeldes des IP-Paketes gekennzeichnet ist, ein der jeweiligen empfangenden Schnitt stelle zugeordneter eineindeutiger Wert, der sich von den Werten der jeweils anderen Schnittstellen unterscheidet, in einem bestimmten Feld des Kopffeldes des IP-Paketes eingetragen wird und das derart veränderte Paket durch den mindestens einen IP-Tunnel zur Steuerkomponente weitergeleitet wird.
4. Verfahren nach Anspruch 3 d a d u r c h g e k e n n z e i c h n e t, dass mindestens ein IP-Tunnel vom Netzknoten zur Steuerkompo- nente eingerichtet wird und dass ein an einer Schnittstelle des Netzknotens empfangenes IP Paket des Typs "RSVP" erkannt, der Wert des "DSCP" Feldes im Kopf des IP Paketes in Abhängigkeit von der empfangenden Schnittstelle verändert und das veränderte Paket durch den mindestens einen IP-Tunnel zur Steuerkomponente weitergeleitet wird.
5. Verfahren zur Weitergabe von Internet-Protokoll-Paketen respektive IP-Paketen an eine externe Steuerkomponente eines Netzknotens in einem mehrere Netzknoten aufweisenden IP- Pakete vermittelnden, MPLS fähigen Kommunikationsnetz, bei dem IP Pakete an Schnittstellen des Netzknoten empfangen, erkannt, ausgewertet und verarbeitet werden, d a d u r c h g e k e n n z e i c h n e t, dass ein an einer Schnittstelle des Netzknotens empfangenes und erkanntes In-Band IP Signalisierungspaket, das durch einen Eintrag im Protokollfeld des Kopffeldes des IP-Paketes gekennzeichnet ist, derart verarbeitet wird, dass dem In-Band IP Signalisierungspaket ein von der empfangenden Schnittelle des Netzknotens abhängiges MPLS-Label vorangestellt wird und dieses veränderte Paket durch das MPLS-Verfahren an die externe Steuerkomponente weitergeleitet wird.
6. Verfahren nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t, dass ein an einer Schnittstelle des Netzknotens empfangenes IP Paket des Typs „RSVP" erkannt und derart verarbeitet wird, dass dem IP-Paket des Typs „RSVP" ein von der empfangenden Schnittelle des Netzknotens abhängiges MPLS-Label vorangestellt wird und dieses veränderte Paket durch das MPLS- Verfahren an die externe Steuerkomponente weitergeleitet wird.
7. Verfahren zur Weitergabe von Internet-Protokoll-Paketen respektive IP-Paketen an eine externe Steuerkomponente eines Netzknotens in einem mehrere Netzknoten aufweisenden IP- Pakete vermittelnden, MPLS fähigen Kommunikationsnetz, bei dem IP Pakete an Schnittstellen des Netzknoten empfangen, erkannt, ausgewertet und verarbeitet werden, d a d u r c h g e k e n n z e i c h n e t, dass ein an einer Schnittstelle des Netzknotens empfangenes und erkanntes In-Band IP Signalisierungspaket, das durch einen Eintrag im Protokollfeld des Kopffeldes des IP-Paketes gekennzeichnet ist, derart verarbeitet wird, dass ein der jeweiligen empfangenden Schnittstelle zugeordneter eineindeutiger Wert, der sich von den Werten der jeweils anderen Schnittstellen unterscheidet, in einem bestimmten Feld des
Kopffeldes des IP-Paketes eingetragen wird, diesem veränderten Paket ein MPLS-Label vorangestellt wird und durch das MPLS-Verfahren an die Steuerkomponente weitergeleitet wird.
8. Verfahren nach Anspruch 7, d a d u r c h g e k e n n z e i c h n e t, dass ein an einer Schnittstelle des Netzknotens empfangenes IP Paket des Typs „RSVP" erkannt und derart verarbeitet wird, dass der Wert des „DSCP" Feldes in Abhängigkeit von der emp- fangenden Schnittstelle verändert wird, dass dem IP-Paket des Typs „RSVP" ein MPLS-Label vorangestellt wird und dieses veränderte Paket durch das MPLS- Verfahren an die Steuerkomponente weitergeleitet wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t, dass die Steuerkomponente direkt am Netzknoten angeschlossen ist.
PCT/EP2004/050950 2003-05-30 2004-05-27 Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz Ceased WO2004107675A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/558,901 US20060268911A1 (en) 2003-05-30 2004-05-27 Method for routing ip-packets to an external control comonent of a network node in an ip-packet switching communications network comprising several network nodes
EP04741669A EP1629641A2 (de) 2003-05-30 2004-05-27 Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz
US12/352,013 US20090180485A1 (en) 2003-05-30 2009-01-12 Method for routing ip packets to an external control component of a network node in an ip packet switching communications network comprising several network nodes

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10324604.5 2003-05-30
DE10324604A DE10324604A1 (de) 2003-05-30 2003-05-30 Verfahren zur Weitergabe von IP-Paketen an eine externe Steuerkomponente eines Netzknotens in einem mehrere Netzknoten ausweisenden IP-Pakete vermittelnden Kommunikationsnetz

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/352,013 Continuation US20090180485A1 (en) 2003-05-30 2009-01-12 Method for routing ip packets to an external control component of a network node in an ip packet switching communications network comprising several network nodes

Publications (2)

Publication Number Publication Date
WO2004107675A2 true WO2004107675A2 (de) 2004-12-09
WO2004107675A3 WO2004107675A3 (de) 2005-04-07

Family

ID=33482314

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/050950 Ceased WO2004107675A2 (de) 2003-05-30 2004-05-27 Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz

Country Status (4)

Country Link
US (2) US20060268911A1 (de)
EP (1) EP1629641A2 (de)
DE (1) DE10324604A1 (de)
WO (1) WO2004107675A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102132533A (zh) * 2008-08-26 2011-07-20 艾利森电话股份有限公司 网络中的分组转发

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102273136B (zh) 2009-09-01 2012-12-26 华为技术有限公司 隧道多业务性能检测方法和装置
US8891406B1 (en) * 2010-12-22 2014-11-18 Juniper Networks, Inc. Methods and apparatus for tunnel management within a data center

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6101549A (en) * 1996-09-27 2000-08-08 Intel Corporation Proxy-based reservation of network resources
US7203740B1 (en) * 1999-12-22 2007-04-10 Intel Corporation Method and apparatus for allowing proprietary forwarding elements to interoperate with standard control elements in an open architecture for network devices
US6865185B1 (en) * 2000-02-25 2005-03-08 Cisco Technology, Inc. Method and system for queuing traffic in a wireless communications network
US7046680B1 (en) * 2000-11-28 2006-05-16 Mci, Inc. Network access system including a programmable access device having distributed service control
US7215638B1 (en) * 2002-06-19 2007-05-08 Meshnetworks, Inc. System and method to provide 911 access in voice over internet protocol systems without compromising network security
AU2002320892A1 (en) * 2002-06-25 2004-01-06 Siemens Aktiengesellschaft Communication network and method for operating the same
US7023843B2 (en) * 2002-06-26 2006-04-04 Nokia Corporation Programmable scheduling for IP routers
US7359984B1 (en) * 2002-07-15 2008-04-15 Packeteer, Inc. Management of network quality of service

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102132533A (zh) * 2008-08-26 2011-07-20 艾利森电话股份有限公司 网络中的分组转发

Also Published As

Publication number Publication date
WO2004107675A3 (de) 2005-04-07
US20090180485A1 (en) 2009-07-16
DE10324604A1 (de) 2004-12-23
EP1629641A2 (de) 2006-03-01
US20060268911A1 (en) 2006-11-30

Similar Documents

Publication Publication Date Title
DE60225892T2 (de) Firewall zur Filtrierung von getunnelten Datenpaketen
DE60037368T2 (de) Verfahren und Architektur zur Unterstüzung von mehreren Diensten in einem Etikettvermittlungsnetzwerk
EP2676409B1 (de) Schleifen von mpls pfaden auf weiterleitungsebene für verbindungslose mpls netze
WO2003030468A2 (de) Verfahren und vorrichtung zur anpassung von label-switched-pfaden in paketnetzen
EP1438829B1 (de) Verfahren und vorrichtung zur abbildung von netzwerk-headern auf mpls-header in bearer-architekturen
WO2003007484A2 (de) Verfahren zur optimierten nutzung von sctp (stream control transmission protocol) in mpls (multi protocol label switching) netzen
WO2003094444A1 (de) Verfahren zur überprüfung der durchgängigkeit von verbindungen in mpls-netzen
WO2003030485A1 (de) Verfahren und vorrichtungen zur header-kompression in paketorientierten netzwerken
EP1262084B1 (de) Verfahren zum ersatzschalten von übertragungseinrichtungen in mpls-netzen
EP1317820B1 (de) Verfahren zum aufbau von verbindungen mit vorgegebener dienstgüte für ein paketorientiertes kommunikationsnetz mit einem resourcenmanager
WO2020109015A1 (de) Datenübertragungsverfahren und automatisierungskommunikationsnetzwerk
WO2004107675A2 (de) Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens in einem mehrere netzknoten aufweisenden ip-pakete vermittelnden kommunikationsnetz
DE69921776T2 (de) Mobiles IP mit Dienstqualität für fremdes Netz mit fremdem Agent und mehreren mobilen Knoten
DE10119447A1 (de) Verfahren zum Vermitteln von Daten zwischen einem lokalen Netzwerk und einem externen Gerät und Router dafür
EP1488582A1 (de) Verfahren für den betrieb und die überwachung von mpls-netzen
DE60111848T2 (de) Telekommunicationssystem mit verteilten Breitband-Fernzugriffsservern
EP1894363B1 (de) Verfahren und unabhängiges kommunikationsteilnetz zum ermitteln labelvermittelter routen in einem solchen kommunikationsteilnetz
EP1629639B1 (de) Verfahren zur weitergabe von ip-paketen an eine externe steuerkomponente eines netzknotens
EP0998093B1 (de) Verfahren zur Übertragung von Rückkanal-Daten in einer Verbindung zwischen einem Endgerät und einem Server eines Paketvermittlungsnetzes
DE60203539T2 (de) Mehrfach-domain-zugriffsregelung von datenflüssen in assoziation mit dienstqualitätskriterien
DE10324370A1 (de) Netzknoten eines paketvermittelnden Kommunikationsnetzes und Verfahren zur Verkehrsverteilung von Datenverkehr in einem paketvermittelnden Kommunikationsnetz
DE10055066A1 (de) Verfahren zum multidirektionalen Austausch von Informationen zwischen Teilnehmern auf Ethernet Basis
DE10062375B4 (de) Verfahren zum Weiterleiten von Datenpaketen, Weiterleitungseinheit und zugehöriges Programm
DE10319322A1 (de) Verfahren zur Unterstützung einer automatischen Konfiguration einer Kommunikationseinrichtung
DE102005052188B4 (de) Dienstqualitätssicherung mit Hilfe zentral erfasster Dienstgüteparameter

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004741669

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006268911

Country of ref document: US

Ref document number: 10558901

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2004741669

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10558901

Country of ref document: US

WWW Wipo information: withdrawn in national office

Ref document number: 2004741669

Country of ref document: EP