EP1774730A1 - Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz - Google Patents

Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz

Info

Publication number
EP1774730A1
EP1774730A1 EP05777989A EP05777989A EP1774730A1 EP 1774730 A1 EP1774730 A1 EP 1774730A1 EP 05777989 A EP05777989 A EP 05777989A EP 05777989 A EP05777989 A EP 05777989A EP 1774730 A1 EP1774730 A1 EP 1774730A1
Authority
EP
European Patent Office
Prior art keywords
route
traffic
message
network element
resource reservation
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
EP05777989A
Other languages
English (en)
French (fr)
Inventor
Thomas Engel
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.)
Nokia Solutions and Networks GmbH and Co KG
Original Assignee
Siemens AG
Nokia Siemens Networks GmbH and Co KG
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, Nokia Siemens Networks GmbH and Co KG filed Critical Siemens AG
Publication of EP1774730A1 publication Critical patent/EP1774730A1/de
Withdrawn 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/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • 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/02—Topology update or discovery
    • 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/02—Topology update or discovery
    • H04L45/023—Delayed use of routing table updates
    • 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/02—Topology update or discovery
    • H04L45/033—Topology update or discovery by updating distance vector protocols
    • 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/02—Topology update or discovery
    • H04L45/04—Interdomain routing, e.g. hierarchical 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/22—Alternate 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/28—Routing or path finding of packets in data switching networks using route fault recovery
    • 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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • H04L47/785—Distributed allocation of resources, e.g. bandwidth brokers among multiple network domains, e.g. multilateral agreements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/826—Involving periods of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction

Definitions

  • the invention relates to a method for setting a route for the routing of traffic and a network element with means for carrying out such a method.
  • a currently very active field in the field of networks and network technologies is the further development of data networks for the transmission of real-time traffic in compliance with quality of service characteristics.
  • IP Internet Protocol
  • QoS Quality of Service
  • Inter-Domain Routing Routing along individual networks or autonomous systems is often referred to as Inter-Domain Routing or Inter-Domain Routing.
  • a border router announces a route change by means of an UPDATE message (announcement of a new route, withdrawal of an existing route, or both).
  • UPDATE message announcement of a new route, withdrawal of an existing route, or both.
  • Such a route change generally spreads over many UPDATE messages from network to network across many networks. More distant networks generally receive multiple UPDATE messages over multiple paths and see different routes from which they receive their
  • BGRP Band Gateway Reservation Protocol
  • Protocol provided routes the required resources.
  • a resource reservation must follow the route changes initiated by the BGP protocol, i. When changing a route, make a correspondingly changed reservation. This poses major problems, especially during the convergence period, when a network is looking for a new stable route across multiple routes. Intermediate routes are not immediately recognizable as temporary solutions. If the resource management quickly follows the route changes, multiple resources are reserved for the same traffic. If resource management is waiting for convergence, the assured quality of service of the QoS traffic can be violated for a long time.
  • the object of the invention is to specify a method for determining routes optimized with regard to compliance with quality of service characteristics.
  • the object is achieved by a method according to claim 1 and a network element according to claim 19.
  • the invention is based on the idea of determining a route, e.g. in the course of a route change or announcement of a new route, announce this route once before it is put into operation or activated with a time delay, e.g. by making a corresponding entry in a routing table.
  • the announcement of the route preferably consists of the message of the future route. It is, however, e.g. also possible, as part of the announcement already held as an alternative
  • the invention is primarily intended to overcome problems in determining inter-domain routes, eg by means of the BGP protocol, by the comparatively slow convergence in the determination of new or changed routes. These slow convergence times are above all a problem in the transmission of real-time traffic.
  • an announcement is made first and later, with a time delay, activation of the route.
  • a convergence can take place with respect to the new or changed route, i. among several advertised routes to the same destination, the optimal one is selected in terms of a metric, and a resource reservation along that optimal route can be made. In this way the required resources are available when activating the route.
  • the traffic to be carried in particular QoS traffic, can be diverted without impairment. It is conceivable to use the method according to the invention and the conventional procedure in parallel, the method according to the invention being used when QoS traffic is concerned.
  • Planned route changes i. Not due to line and node failure conditional Umrouten can be performed with the inventive method without disturbing the QoS traffic assured quality of service.
  • the method thus increases the availability of QoS services and simplifies resource management.
  • the quality of service of QoS services in the planned re-routing of cross-network traffic flows can thus be ensured. In particular, it supports traffic engineering of cross-network traffic, which network operators are already practicing with growing importance.
  • the inventive idea is not limited to this case. It will be readily apparent to those skilled in the art that the inventive approach may be applied to any communications network in which problematic delays occur in defining new or changed routes. In particular, the method according to the invention could also be used in intradomain routing if similar difficulties with respect to convergence times occur in intradomain routing.
  • the event which initiates the commissioning of the new route or activates the new route is preferably given by the transmission of a route activation message, which will also be referred to as activation in the following.
  • a network element which takes a new route into operation, then receives two different temporally delayed messages; one to announce a route change, the second to activate this route change.
  • the event that causes the commissioning but could also have a different form, for example, it is conceivable that a network element after receiving a route change message starts a timer or timer and the startup is caused by the expiry of this timer.
  • Route activation message may e.g. be given by an UPDATE message of the BGP protocol.
  • Resource reservation takes place. This resource reservation may be preceded by a selection of an optimal route.
  • the resource reservation for the new (possibly optimally identified) route may, for example, be realized by means of a resource reservation message sent to a resource management entity.
  • the address of this resource management entity can be used for route determination by means of the route announcement message responsible network element. The ones affected by the resource reservation
  • Resource management entities are located in a preferred embodiment along the route to be determined.
  • a resource reservation message is transmitted from the network element along a route established with the processing of the route announcement message, which in its course corresponds to the new route and allows the sending of reservation messages without affecting existing traffic. This is done with the
  • Processing the route announcement message preferably set a route with a prefix, which is announced with the route announcement message and contains an address of a resource manager in the system that has originally caused the route announcement.
  • a message can thus be propagated along the entire route; alternatively, the routing entities located on the new route in turn send resource reservation messages to associated resource management entities to ensure resource reservation all the way. Since resource reservation messages run in the reverse direction on the way of route announcement messages, the allocation of a resource management instance can be easily deduced from the route announcement message.
  • a successful resource reservation can be confirmed to the network element responsible for route setting.
  • the activation of the route can be made dependent on the previous receipt of a confirmation of the reservation, ie the activation is not made if there is no confirmation for the resource reservation.
  • activation can be prevented, for example by no route activation message being sent to the network element. Further, the activation may be made dependent on that mentioned in the route announcement messages Resource manager receives reservations in response to its announcement whose total resource requirements are within a target interval.
  • the route announcement message preferably contains a flag or attribute which identifies it as an announcement message.
  • information about the time of occurrence of the event e.g. the time of sending a route activation message are transmitted. This information can exist both in a time difference between the announcement message and the activation-triggering event, as well as in an absolute time of the planned occurrence of the activation event. In the latter case, a synchronization of
  • the route advertisement message may be substantially in the form of a BGP UPDATE message, but is modified relative to conventional UPDATE messages, at least insofar as it should include a label as an advertisement message. It may include time of occurrence information and an address of a competent resource management entity, which is also an extension to conventional UPDATE messages.
  • the method according to the invention then runs as follows in a preferred embodiment implemented by means of UPDATE messages.
  • Traffic engineering and other scheduled traffic triggers advance announcements of route changes. If current traffic in the future, instead of a previously used border router Rl, via another border router R2 in an autonomous system A reach, so be led on new ways, then sends the future to be used border router R2 as conventional BGP UPDATE message to the affected neighbors. In contrast to however, it sends an UPDATE message Ul with a previous announcement of the new route. Later, at an announced time, R2 sends a second, regular UPDATE message U2 with the new route announced in Ul.
  • the UPDATE message Ul announces U2 and gives the participating networks the opportunity to pre-run the convergence process without disturbing the current traffic, to reserve the resources on the new converged route and to disrupt the affected traffic with the propagation of U2 in one step to map a prepared route.
  • new attributes are inserted in UPDATE messages: for the announcement of announcements, for the announcement of the dispatch time of U2 and for the announcement of the address of a resource manager in A to be sent to the reservations for the announced route.
  • an advertisement also contains a route consisting of a prefix P, a route R coded in a list of AS numbers and attributes. The prefix P, route R and attributes are identical to those in U2.
  • the border router R2 could send an advertisement Ul without specifying the time of the planned sending of the actual UPDATE message U2 and wait only for a reasonable time before sending U2 (estimates about distribution of the route lengths) and a responsive one AS could also wait for a suitable period of time until signaling for resource reservation (estimation of distribution of route lengths).
  • Ul could include a time interval that is adapted from Border Router to Border Router (deducting forwarding and processing time) and indicating the time remaining until U2 is posted.
  • the UPDATE U2 may contain a reference to Ul and make it easier to link to the advertised route change.
  • the subject matter of the invention also comprises a network element with means for carrying out a method in the sense of the procedure according to the invention.
  • Fig. 1 A section of a network network, which is formed with autonomous systems (AS).
  • AS autonomous systems
  • FIG. 2 and Fig. 3 A flow chart for carrying out a method according to the invention.
  • route changes in the inter-domain routing by means of the BGP protocol with a new form of UPDATE messages are announced in advance.
  • a few minutes later than the announcement the actual route change takes place, which can take place as usual in the BGP protocol.
  • the time delay is chosen so that usually before the route change the optimal route determined and a resource reservation can be made. Since an average convergence process takes about 3 minutes for inter-domain routing, a time delay of a few minutes makes sense.
  • the convergence phase and the resource reservation for QoS traffic can be brought forward in the time between the announcement and the actual re-routing. It will not be re-routed to the announcement until the convergent route is already known and the required resources have already been provisioned.
  • Route announcements are transported via UPDATE messages and undergo the same convergence process as regular UPDATE messages, but do not change the traffic flow, but cause the determination of the later convergent route.
  • new attributes are used in BGP UPDATE messages, with which a route change can be announced in advance with an UPDATE message U1 (hereinafter also referred to as announcement this route announcement message).
  • UPDATE message U1 hereinafter also referred to as announcement this route announcement message.
  • the attributes show the UPDATE message as an announcement of a route change.
  • Ul in the order of minutes after the sending of Ul
  • a re-routing is initiated with a regular second UPDATE message U2.
  • the UPDATE message U2 contains the achievable prefixes and the AS path in the usual way, ie the IP addresses of the accessible systems and the list of autonomous systems leading to the destination.
  • the UPDATE message Ul which is used as an announcement, contains the same
  • Information such as U2 plus additional information: an indicator that it is an announcement of an upcoming new route, the time at which the second UPDATE message U2 initiates the actual route change, and the address of a resource reservation resource manager.
  • this resource manager is located in the autonomous system that originally announces the route change with the UPDATE message Ul.
  • This resource manager is located at the edge router R12 in the example of FIG.
  • a resource manager may e.g. be realized by software through processes running on a router or on an independent hardware platform. Central resource management is also possible.
  • each edge router e.g. Inbound UPDATES filter, best path selection, and outbound UPDATE filters that use route dialing and -
  • each destination has at most one route - the best route - passed on to neighboring nodes. This restriction does not affect the propagation of advertised routes.
  • Announced routes if they have successfully passed through the selection processes and are modified as well as analogous regular routes, are passed on to all neighbors, as well as later on the routes triggered or activated by the UPDATE message U2.
  • announcements do not affect the current best route of the traffic concerned used for routing, in particular they do not change the corresponding entry in routing tables (FIB) and do not replace routes learned via regular UPDATE messages. Like later the UPDATE message U2 triggers the announcement Ul convergence processes.
  • a remote autonomous system B which will later respond to U2 and move QoS traffic, will undergo a convergence process and will already be learning the routes available later, and in particular the converged route to be subsequently set, to which the traffic will then be transferred.
  • the autonomous system B reserves the resources needed to transfer the affected traffic on the converged, best future route learned from the announcements. For a corresponding
  • Fig.l shows seven autonomous systems ASl, AS2, ..., AS7.
  • Two networks are connected to ASl, network N1 and network N2.
  • Address block 10.10.11.0/24 i. 10.10.11.0 to 10.10.11.255.
  • 10.10.10.0/24 specifies an IP address, 10.10.10.0, and a mask length, 24, and stands for all IP addresses that match the specified address 10.10.10.0 in the first 24 bits (mask length), ie 10.10.10.0 to
  • FIG. 1 Only part of the participating routers, the border routers or edge routers, via which the autonomous systems are connected to one another, are shown in FIG. 1: R1, R2, R21, R22, R31, R32, R33, R41, R42, R51, R52 , R61, R62, R71 and R72. Also only partially shown are the components responsible for resource management. As exemplified by the resource managers RMlI, RM12, RM61 and RM62, in particular each border router is assigned a resource manager.
  • Routes in this example are represented in the form (P, a1, a2, ..., aN).
  • the prefix P describes the address block with the reachable destination addresses and the following sequence al, a2,..., AN the sequence of the autonomous systems to be traversed by the traffic
  • (10.10.10.0/23, 4, 2, 1) is a route from the AS6 autonomous system. It leads with the address block 10.10.10.0/23 to the networks N1 and N2.
  • the numerical sequence 4, 2, 1 stands for the sequence of autonomous systems: AS4, AS2, ASl, which forward the traffic from the autonomous system AS6 to the networks N1 and N2.
  • AS4, AS2, ASl stands for the sequence of autonomous systems: AS4, AS2, ASl, which forward the traffic from the autonomous system AS6 to the networks N1 and N2.
  • the autonomous system AS6 uses the route (10.10.10.0/23, 4, 2, 1) for the traffic to the target networks Nl and N2
  • the utilization of the connection between the routers R21 and RlI approaches the capacity limit and the autonomous system ASl wants to move part of the traffic to other routes.
  • the autonomous system AS1 decides to switch the traffic to the network N2 to routes via R12.
  • the router RlI would limit the reachable through him destination addresses with an UPDATE message to 10.10.10.0/24 and the router R12 with an UPDATE message the availability of 10.10.11.0/24 announce. This would initiate a generally average three-minute convergence process during which the quality of service for traffic flows from the autonomous system AS6 to the networks N1 and N2 suffers significantly and possibly during the convergence process multiple resources are reserved on different paths between the autonomous systems AS6 and AS1.
  • the router R12 sends an UPDATE message Ul to the router R31 containing an announcement of the route (10.10.11.0/24, 1). In Ul could be that this route is communicated in 10 minutes with another UPDATE message binding.
  • AS3 propagates the advertised route as (10.10.11.0/24, 3, 1) to routers R41, R51 and R71.
  • the autonomous system AS4 propagates the announced route as (10.10.11.0/24, 4, 3, 1) to the autonomous system AS6, although the router R42 already (10.10.10.0/23, 4, 3, 1) to the router R61 has passed.
  • the convergence phase is completed in this example when (10.10.11.0/24, 4, 3, 1) via the router R42, (10.10.11.0/24, 5, 3, 1) via the router R52 and
  • the autonomous system AS6 will inform its resource management timely about its route selection and cause the resource manager RM62 to signal the required resources on the selected future route to the resource manager RM12.
  • the new route is established, and the required resources are already provided when the router R12 at the announced time sends another UPDATE message U2 with the route (10.10.11.0/24, 1) to the router R31, this time as a regular UPDATE message .
  • the U2 UPDATE will trigger messages with the routes (10.10.11.0/24, 4, 3, 1), (10.10.11.0/24, 5, 3, 1) and (10.10.11.0/24 , 7, 3, 1) arrive at the autonomous system AS6.
  • the AS6 autonomous system already knows the new converged route and will wait until the UPDATE message arrives with the route (10.10.11.0/24, 5, 3, 1). Then the autonomous system AS6 will adjust its routing and set the traffic to N2 on the new path, which is already consistent at this time, representing the convergent state and holding the required resources. Without significant impairment of the quality of service, the traffic is thus switched to the new route (except for possible overlaps of traffic on the new route and still on the old
  • the resource manager RM61 will then adapt the resources reserved on the old route via the autonomous systems AS4, AS2 and AS1, ie release the resources no longer required by the traffic transfer.
  • the autonomous system AS6 proceeds according to the flowchart shown in FIG. 2 and FIG. For simplicity, it is assumed here that an UPDATE contains only a known route R with prefix P (step 101). An extension to UPDATE messages that announce multiple routes is trivial to one skilled in the art. Steps 102, 104, 105, 107, 108, and 109 correspond to the routes disclosed in RFC1771. In step 106, route announcements are filtered out in this course, which describe future best route, and in a new one
  • Announced Route Database, Pen-RIB (Pen for Pending)) (step 123). If R is the first such route announcement for the prefix P (no entry in pen RIB), a timer is started (steps 121 and 122). From the route announcement R, a route R * is generated which is identical to R except for the prefix P * (step 124). P * is the prefix of the resource manager responsible for reservations on the announced route, in the example a prefix for an address of RM12 in ASl. R * is now entered and activated in Loc-RIB instead of the route announcement (step 125). Announced routes that are expected due to the route announcements entered in Pen-RIB will be filtered out in step 103 and treated separately.
  • Step 131 a timer is started (steps 132 and 133). If Route R corresponds to the new best route contained in Pen-RIB, all routes cached in Pen-RIB for Prefix P are processed and all entries for Prefix P in Pen-RIB are deleted (Step 1).
  • step 135 corresponds to that of steps 104, 105, 107, 108 and 109.
  • step 201 When a timer set up in step 122 expires (step 201), resource management is informed of the upcoming route change by a corresponding one
  • step 202 To cause resource reservation (step 202). If a timer set up in step 133 expires (step 301), it is assumed that the timer in pen RIB stored new best route has lost its validity. It is checked if there are entries for the prefix P in pen RIB (step 302). If so, all routes cached in pen RIB to prefix P are processed (step 303) and deleted in pen RIB (step 304). Further, resource management is informed of the change (step 305).
  • route change messages may have to be given an appropriate value for this identification, e.g. an AS number or an IP address of a border router.

Landscapes

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

Abstract

Erfindungsgemäß wird eine Route für das Routen von Verkehr festgesetzt, indem zunächst an ein Netzelement (R62) eines Netzes (AS6) eine Routenankündigungsnachricht zur Ankündigung einer Route gesendet wird. Zeitverzögert dazu wird das Netzelement (R62) durch ein Ereignis, z.B. Senden einer weiteren Nachricht, dazu veranlasst, Verkehr nach Maßgabe der angekündigten Route zu routen. Zwischen der Routenankündigung und dem Ereignis kann eine Ressourcenreservierung für die Übertragung von Verkehr entlang der angekündigten Route vorgenommen werden. Auf diese Weise ist bei Umlegen von Verkehr auf die neue Route sichergestellt, dass die erforderlichen Ressourcen bereitstehen. Dadurch kann ohne Beeinträchtigung der Dienstgüte eine Routenänderung für Verkehr vorgenommen werden.

Description

Beschreibung
Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz
Die Erfindung betrifft ein Verfahren zur Festsetzung einer Route für das Routen von Verkehr und ein Netzelement mit Mitteln zur Durchführung eines derartigen Verfahrens .
Ein derzeit sehr aktuelles Arbeitsfeld auf dem Gebiet der Netze und Netztechnologien ist die Weiterentwicklung von Datennetzen für die Übertragung von Echtzeitverkehr unter Einhaltung von Dienstgütemerkmalen.
Zukünftig sollen Datennetze, deren wichtigste Vertreter die sogenannten IP-Netze (IP: Internent Protocol) sind, Anwendungen unterstützen, die die Übertragung von Sprach-, Video- und Datenströmen in Echtzeit beinhalten. Für diese Anwendungen muss ein schneller und zuverlässiger Transport von Datenpaketen bzw. IP-Paketen gewährleistet werden. Dafür sollen zukünftige IP-Netze - neben den traditionellen "best effort" Diensten für Datenübertragung - neue
Übertragungsdienste anbieten, die dem Verkehr die benötigten Bandbreiten durchgängig bereitstellen und IP-Pakete mit geringen, kaum schwankenden Verzögerung und sehr geringen Paketverlustraten (d.h. unter Einhaltung von Dienstgütemerkmalen) zuverlässig zum Empfänger übertragen. Diese neuen Dienste werden im Folgenden QoS-Dienste (QoS: Quality of Service) und der von ihnen transportierte Verkehr QoS-Verkehr genannt.
Da das Internet ein Zusammenschluss einer wachsenden Anzahl einzelner IP-Netze, sogenannter autonomer Systeme (AS) , ist, die von unterschiedlichen Organisationen verwaltet und gesteuert werden, müssen QoS-Dienste in diesem Netzverbund netzübergreifend realisiert und zur Verfügung gestellt werden. Dafür werden in der Regel Ressourcenmanagementsysteme eingesetzt, die dem QoS-Verkehr die für die zugesicherte Dienstgüte erforderlichen Ressourcen netzübergreifend bereitstellen. Aus verschiedenen Gründen, wie Traffic- Engineering und Veränderungen von Netzen und Geschäfts¬ beziehungen, wird netzübergreifender Verkehr häufig auf neue netzübergreifende Routen umgelegt. Das netzübergreifende
Routen entlang von einzelnen Netzen oder autonomen Systemen wird häufig auch als Inter-Domänen Routing oder Zwischen- Domänen Routing (vom engl. Inter-domain routing) bezeichnet.
Das Zusammenspiel autonomer System im Internet, d.h. die netzübergreifende Weiterleitung von IP-Paketen über die Grenzen einzelner IP-Netze hinweg, wird mit dem inter-domain Routing-Protokoll BGP (BGP: boder gateway protocol) geregelt (beschrieben im RFC1771) . Dazu bauen benachbarte Border- Router oder Randrouter sogenannte BGP-Peering-Sessions auf und tauschen über sogenannte UPDATE Nachrichten Routing- Informationen aus. Mittels BGP lernt ein Netz, welche IP- Adressen über welche Routen erreichbar sind. Routen sind hier netzübergreifende Routen auf der Ebene autonomer Systeme und werden als Sequenzen von AS-Nummern (AS: autonomes System) kodiert. Für diesen Zweck sind autonomen Systemen eindeutige AS-Nummern zugeordnet. Soll Verkehr auf eine neue Route umgelegt werden, dann gibt ein Border-Router mittels einer UPDATE Nachrichte eine Routenänderung bekannt (Bekanntgabe einer neuen Route, Zurücknahme einer bestehenden Route, oder beides) . Eine derartige Routenänderung breitet sich im Allgemeinen über weitere UPDATE Nachrichten von Netz zu Netz über viele Netze hinweg aus . Weiter entfernte Netze erhalten im Allgemeinen über mehrere Wege mehrere UPDATE Nachrichten und sehen verschiedenen Routen, aus denen sie die aus ihrer
Sicht beste Route auswählen. Das heißt, mit dem ersten UPDATE wird ein Konvergenzprozess gestartet, der nach Messungen durchschnittlich etwa drei Minuten dauert. Während der Konvergenzzeit wird der betroffene Verkehr in der Regel mehrfach auf wechselnde Routen umgelegt, weshalb mit erheblichen Verzögerungen von IP-Paketen und hohen Paketverlustraten gerechnet werden muss. Für die Bereitstellung und Verwaltung der für QoS-Dienste benötigten Ressourcen werden Ressourcemanagementsysteme und Signalisierungsprotokolle wie zum Beispiel BGRP (BGRP: Border Gateway Reservation Protocol) verwendet. Das Ressourcemanagement reserviert entlang der durch das BGP
Protokoll bereitgestellten Routen die benötigten Ressourcen. Eine Ressourcenreservierung muss den durch das BGP Protokoll initiierten Routenänderungen folgen, d.h. bei Änderung einer Route eine entsprechend geänderte Reservierung vornehmen. Das macht vor allem während der Konvergenzzeit, in der sich ein Netz über mehrere Routen hinweg eine neue stabile Route sucht, große Probleme. Zwischenzeitlich gewählte Routen sind nicht unmittelbar als Zwischenlösungen erkennbar. Folgt das Ressourcemanagement den Routenänderungen schnell, so werden für denselben Verkehr mehrfach Ressourcen reserviert. Wartet das Ressourcemanagement auf Konvergenz, kann über längere Zeit die zugesicherte Dienstgüte des QoS-Verkehrs verletzt sein.
Die Erfindung hat zur Aufgabe, ein bezüglich der Einhaltung von Dienstgütemerkmalen optimiertes Verfahren zum Festlegen von Routen anzugeben.
Die Aufgabe wird durch ein Verfahren nach Anspruch 1 und ein Netzelement nach Anspruch 19 gelöst.
Die Erfindung basiert auf dem Gedanken, bei der Festsetzung einer Route, z.B. im Rahmen einer Routenänderung oder einer Bekanntgabe einer neuen Route, diese Route erst einmal anzukündigen, bevor sie zeitverzögert in Betrieb genommen bzw. aktiviert wird, z.B. indem ein entsprechender Eintrag in einer Routingtabelle vorgenommen wird. Dabei besteht die Ankündigung der Route vorzugsweise aus der Mitteilung der zukünftigen Route. Es ist aber z.B. auch möglich, im Rahmen der Ankündigung eine bereits als Alternative vorgehaltene
Route zu referenzieren, um so eine Aktivierung der Route zu bewirken. Die Erfindung ist primär gedacht, um bei der Festsetzung von Interdomain-Routen, z.B. mittels des BGP Protokolls, Probleme durch die vergleichsweise langsame Konvergenz bei der Bestimmung bzw. Festsetzung von neuen oder geänderten Routen zu überwinden. Diese langsamen Konvergenzzeiten sind vor allem ein Problem bei der Übertragung von Echtzeitverkehr. Im Rahmen des erfindungsgemäßen Vorgehens erfolgt zuerst eine Ankündigung und später zeitversetzt eine Aktivierung der Route.
In der Zwischenzeit kann eine Konvergenz bezüglich der neuen oder geänderten Route stattfinden, d.h. unter mehreren angekündigten Routen zu demselben Ziel wird die optimale im Sinne einer Metrik ausgewählt und eine Ressourcenreservierung entlang dieser optimalen Route kann vorgenommen werden. Auf diese Weise stehen bei der Aktivierung der Route die erforderlichen Ressourcen zur Verfügung. Der zu befördernde Verkehr, insbesondere QoS-Verkehr, kann ohne Beeinträchtigungen umgelenkt werden. Es ist denkbar, das erfindungsgemäße Verfahren und die herkömmliche Vorgehensweise parallel zu verwenden, wobei das erfindungsgemäße Verfahren dann angewendet wird, wenn QoS- Verkehr betroffen ist.
Geplante Routenänderungen, d.h. nicht durch Leitungs- und Knotenausfall bedingtes Umrouten, können mit dem erfindungsgemäßen Verfahren ohne Störung der dem QoS-Verkehr zugesicherten Dienstgüte durchgeführt werden. Das Verfahren erhöht so die Verfügbarkeit von QoS-Diensten und vereinfacht das Ressourcemanagement. Die Dienstgüte von QoS-Diensten beim geplanten Umrouten netzübergreifender Verkehrsströme kann so sichergestellt werden. Insbesondere wird damit Traffic- Engineering von netzübergreifendem Verkehr unterstützt, was Netzbetreiber schon heute mit wachsender Bedeutung praktizieren.
Auch wenn die Erfindung primär auf eine Behebung der beim Interdomain-Routing in Datennetzen auftretenden Probleme abstellt, ist die erfinderische Idee nicht auf diesen Fall beschränkt. Dem Fachmann ist unmittelbar einsichtig, dass die erfinderische Vorgehensweise in beliebigen Kommunikationsnetzen angewandt werden kann, in welchen problematische Verzögerungen bei der Festlegung neuer oder geänderter Routen auftreten. Insbesondere könnte das erfindungsgemäße Verfahren auch bei einem Intradomain-Routing zur Anwendung kommen, wenn bei dem Intradomain-Routing ähnlich gelagerte Schwierigkeiten bezüglich Konvergenzzeiten auftreten.
Das Ereignis, welches die Inbetriebnahme der neuen Route veranlasst, bzw. die neue Route aktiviert, ist vorzugsweise durch das Senden einer Routenaktivierungsnachricht gegeben, welche im Folgenden auch kurz als Aktivierung bezeichnet wird. Ein Netzelement, welches eine neue Route in Betrieb nimmt, erhält dann zwei verschiedene zeitlich gegeneinander verzögerte Nachrichten; eine um eine Routenänderung anzukündigen, die zweite, um diese Routenänderung zu aktivieren. Das Ereignis, dass die Inbetriebnahme veranlasst, könnte aber auch eine andere Form haben, beispielsweise ist denkbar, dass ein Netzelement nach Erhalten einer Routenänderungsnachricht einen Timer beziehungsweise Zeitgeber startet und die Inbetriebnahme durch den Ablauf dieses Timers veranlasst wird. Eine
Routenaktivierungsnachricht kann z.B. durch eine UPDATE- Nachricht des BGP Protokolls gegeben sein.
Zwischen dem Erhalt der Routenankündigungsnachricht und der Aktivierung der Route findet vorzugsweise eine
Ressourcenreservierung statt. Dieser Ressourcenreservierung geht eventuell eine Auswahl einer optimalen Route voraus . Die Ressourcenreservierung für die neue (eventuell als optimal identifizierte) Route kann beispielsweise mit Hilfe einer Ressourcenreservierungsnachricht realisiert werden, die an eine Ressourcenmanagementinstanz gesendet wird. Die Adresse dieser Ressourcenmanagementinstanz kann mittels der Routenankündigungsnachricht dem für die Routenfestsetzung verantwortlichen Netzelement mitgeteilt worden sein. Die von der Ressourcenreservierung betroffenen
Ressourcenmanagementinstanzen sind in einer bevorzugten Ausführung entlang der festzulegenden Route lokalisiert. In diesem Fall wird eine Ressourcenreservierungsnachricht von dem Netzelement entlang einer Route übertragen, die mit der Verarbeitung der Routenankündigungsnachricht aufgebaut wurde, die in ihrem Verlauf der neuen Route entspricht und das Versenden von Reservierungsnachrichten gestattet ohne bestehenden Verkehr zu beeinflussen. Dazu wird mit der
Verarbeitung der Routenankündigungsnachricht vorzugsweise eine Route mit einem Prefix eingerichtet, der mit der Routenankündigungsnachricht bekannt gegeben wird und eine Adresse eines Ressourcenmanagers in dem System enthält, dass die Routenankündigung ursprünglich veranlasst hat. Eine Nachricht kann so entlang der gesamten Route propagiert werden, alternativ senden die auf der neuen Route gelegene Routinginstanzen ihrerseits Ressourcenreservierungsnachrichten an zugeordnete Ressourcenmanagementinstanzen, um eine Ressourcenreservierung entlang des gesamten Weges zu gewährleisten. Da Ressourcenreservierungsnachrichten auf dem Weg von Routenankündigungsnachrichten in umgekehrter Richtung laufen, kann die Zuordnung einer Ressourcenmanagementinstanz leicht aus der Routenankündigungsnachricht abgeleitet werden.
Entsprechend einer Weiterbildung des Anmeldegegenstands kann eine erfolgreiche Ressourcenreservierung dem für die Routenfestsetzung verantwortlichen Netzelement bestätigt werden. Die Aktivierung der Route kann von dem vorhergehenden Erhalt einer Bestätigung der Reservierung abhängig gemacht werden, d.h. die Aktivierung wird nicht vorgenommen, wenn keine Bestätigung für die Ressourcenreservierung vorliegt. Alternativ kann bei fehlgeschlagener Ressourcenreservierung das Eintreten der Aktivierung verhindert werden, z.B. in dem keine Routenaktivierungsnachricht an das Netzelement gesendet wird. Weiter kann die Aktivierung davon abhängig gemacht werden das der in den Routenankündigungsnachrichten genannte Ressourcenmanager als Reaktion auf seine Ankündigung Reservierungen erhält, deren Ressourcenbedarf in Summe in einen Zielintervall liegen.
Die Routenankündigungsnachricht enthält vorzugsweise ein Kennzeichen oder Attribut, welches sie als Ankündigungsnachricht ausweist. Mit dieser Ankündigungsnachricht kann eine Information über den Zeitpunkt des Eintritts des Ereignisses, z.B. den Zeitpunkt des Sendens einer Routenaktivierungsnachricht übermittelt werden. Diese Information kann sowohl in einer Zeitdifferenz zwischen der Ankündigungsnachricht und dem die Aktivierung auslösenden Ereignis, als auch in einem absoluten Zeitpunkt des geplanten Eintritts des Ereignisses der Aktivierung bestehen. Im letzteren Fall ist eine Synchronisierung der
Uhren des Senders der Nachricht und des Empfängers, d.h. des Netzelementes anzustreben, welche beispielsweise mittels des NTP (Network Time Protocol) Protokolls erreicht werden kann (beschrieben in RFC1305) . Die Routenankündigungsnachricht kann im Wesentlichen die Form einer BGP UPDATE-Nachricht haben, wobei sie bezüglich herkömmlichen UPDATE-Nachrichten zumindest insofern verändert ist, als dass sie eine Kennzeichnung als Ankündigungsnachricht umfassen sollte. Sie kann eine Information über den Eintritt des Zeitpunkts und eine Adresse einer zuständigen Ressourcenmanagementinstanz umfassen, was auch einer Erweiterung bezüglich herkömmlicher UPDATE-Nachrichten darstellt.
Das erfindungsgemäße Verfahren läuft dann in einer mittels UPDATE Nachrichten realisierten, bevorzugten Ausführungsform wie folgt ab. Durch Traffic-Engineering und andere geplante Verkehrsumlegen werden Vorankündigungen von Routenänderungen ausgelöst. Soll laufender Verkehr zukünftig, statt über einen bisher verwendeten Border-Router Rl, über einen anderen Border-Router R2 in ein autonomes System A gelangen, also über neue Wege geführt werden, dann sendet der zukünftig zu nutzende Border-Router R2 wie herkömmlich eine BGP UPDATE Nachricht an die betroffenen Nachbarn. Im Unterschied zum bisherigen Ablauf sendet er jedoch eine UPDATE Nachricht Ul mit einer Vorankündigung der neuen Route. Später, zu einem angekündigten Zeitpunkt, sendet R2 eine zweite, reguläre UPDATE Nachricht U2 mit der in Ul angekündigten neuen Route. Die UPDATE Nachricht Ul kündigt U2 an und gibt den beteiligten Netzen die Gelegenheit, ohne Störung des laufenden Verkehrs den Konvergenzprozess vorab zu durchlaufen, die benötigen Ressourcen auf der neuen konvergenten Route zu reservieren und den betroffenen Verkehr mit der Ausbreitung von U2 störungsfrei in einem Schritt auf eine vorbereitete Route umzulegen. Dazu werden gemäß RFC1771 neue Attribute in UPDATE Nachrichten eingefügt: für die Kennzeichnung von Ankündigungen, für die Bekanntgabe des Versendezeitpunktes von U2 und für die Bekanntgabe der Adresse eines Ressourcemanagers in A an den Reservierungen für die angekündigte Route zu senden sind. Wie eine reguläre UPDATE Nachricht enthält auch eine Ankündigung eine Route bestehend aus einem Prefix P, einer Route R kodiert in einer Liste von AS-Nummern und Attributen. Der Prefix P, Route R und Attribute sind identisch mit denen in U2.
Mögliche Varianten dieser bevorzugten Ausführungsform sind: Der Border-Router R2 könnte eine Ankündigung Ul ohne Angabe des Zeitpunkts des geplanten Versendens der eigentlichen UPDATE Nachricht U2 verschicken und lediglich eine angemessene Zeitspanne vor dem Versenden von U2 abwarten (Abschätzungen über Verteilung der Routenlängen) und ein reagierendes AS könnte ebenfalls eine geeignete Zeitspanne bis zur Signalisierung zur Ressourcenreservierung abwarten (Abschätzungen über Verteilung der Routenlängen) . Alternativ könnte Ul statt einem Zeitpunkt ein Zeitintervall enthalten, dass von Border-Router zu Border-Router angepasst wird (Abzug von Weiterleitungs- und Verarbeitungszeit) und die verbleibende Zeit bis zum Ansenden von U2 anzeigt. Als optionale Verbesserung kann das UPDATE U2 einen Verweis auf Ul enthalten und die Verknüpfung mit der angekündigten Routenänderung erleichtern. Der Gegenstand der Erfindung umfasst auch ein Netzelement mit Mitteln zur Durchführung eines Verfahrens im Sinne der erfindungsgemäßen Vorgehensweise.
Die Erfindung wird im Folgenden im Rahmen eines
Ausführungsbeispiels anhand von Figuren näher erläutert. Es zeigen:
Fig. 1: Einen Ausschnitt aus einem Netzverbund, welcher mit Autonomen Systemen (AS) gebildet ist.
Fig. 2 und Fig. 3: Ein Ablaufdiagramm für die Durchführung eines erfindungsgemäßen Verfahrens .
Im Rahmen des Ausführungsbeispiels werden Routenänderungen bei dem Inter-Domänen Routing mittels des BGP Protokolls mit einer neuen Form von UPDATE Nachrichten vorab angekündigt. Wenige Minuten zeitverzögert zu der Ankündigung erfolgt dann die eigentliche Routenänderung, die wie herkömmlich im BGP Protokoll vorgesehen stattfinden kann. Die Zeitverzögerung wird so gewählt, dass in der Regel vor der Routenänderung die optimale Route bestimmt und eine Ressourcenreservierung vorgenommen werden kann. Da ein durchschnittlicher Konvergenzprozess beim Inter-Domänen Routing ca. 3 Minuten dauert, ist eine Zeitverzögerung von einigen Minuten sinnvoll. Damit können die Konvergenzphase und die Ressourcereservierung für QoS-Verkehr in die Zeitspanne zwischen der Ankündigung und dem eigentlichen Umrouten vorgezogen werden. Umgeroutet wird zeitversetzt zur Ankündigung erst dann, wenn die konvergente Route schon bekannt ist und die benötigten Ressourcen bereits bereitgestellt wurden. Routenankündigungen werden mittels UPDATE Nachrichten transportiert und durchlaufen den selben Konvergenzprozess wie reguläre UPDATE Nachrichten, ändern jedoch der Verkehrsfluss nicht, sondern veranlassen die Ermittlung der später konvergenten Route. Es werden erfindungsgemäß neue Attribute in BGP UPDATE Nachrichten verwendet, mit denen eine Routenänderungen vorab mit einer UPDATE Nachricht Ul angekündigt werden kann (im Folgenden wird diese Routenankündigungsnachricht auch als Ankündigung bezeichnet) . D.h. die Attribute weisen die UPDATE Nachricht als Ankündigung einer Routenänderung aus. Zu einem in der Ankündigung Ul genannten Zeitpunkt (in der Größenordung von Minuten nach dem Versenden von Ul) wird dann wie im Rahmen des BGP Protokolls vorgesehen mit einer regulären zweiten UPDATE Nachricht U2 das Umrouten eingeleitet. Die UPDATE Nachricht U2 enthält in üblicher Weise die erreichbaren Prefixe und den AS-Pfad, d.h. die IP- Adressen der erreichbaren Systeme und die Liste der zum Ziel führenden autonomen Systeme. Die UPDATE Nachricht Ul, welche als Ankündigung verwendet wird, enthält die selben
Informationen wie U2 und zusätzlich Angaben: ein Kennzeichen, dass es sich um eine Ankündigung einer kommenden neuen Route handelt, den Zeitpunkt, an dem mit der zweiten UPDATE Nachricht U2 die eigentliche Routenänderung eingeleitet wird, sowie die Adresse eines für Ressourcenreservierungen zuständigen Ressourcenmanagers. Im Beispiel ist dieser Ressourcenmanager in dem autonomen System lokalisiert, dass die Routenänderung mit der UPDATE Nachricht Ul ursprünglich ankündigt. Diesem Ressourcenmanager ist im Beispiel von Fig. 1 am Rand-Router R12 lokalisiert. Ein Ressourcenmanager kann z.B. mit Hilfe von Software durch Prozesse realisiert werden, die auf einem Router oder auf einer unabhängigen Hardwareplattform laufen. Ein zentrales Ressourcen-Management ist ebenfalls möglich.
Die Ankündigung Ul und alle im weitern Verlauf daraus abgeleiteten Ankündigungen durchlaufen auf jedem Rand-Router die üblichen Selektionsprozesse, z.B. Filter für eingehende UPDATES, Auswahl der besten Route ('best path selection') und Filter für ausgehende UPDATES, die über Routenwahl und -
Weitergabe entscheiden, ohne jedoch das bestehende Routing des von einer Aktivierung der angekündigten Route betroffen Verkehrs zu ändern. Gemäß dem BGP Protokoll wird derzeit zu jedem Ziel maximal eine Route - die beste Route - an Nachbarknoten weitergegeben. Diese Einschränkung beeinflusst die Weitergabe von angekündigten Routen nicht. Angekündigte Routen werden, wenn sie die Selektionsprozesse erfolgreich durchlaufen haben und ebenso modifiziert sind wie analoge reguläre Routen, an alle Nachbarn weitergegeben, so wie später auch die von der UPDATE Nachricht U2 ausgelösten bzw. aktivierten Routen. Ankündigungen beeinflussen dabei aber die fürs Routing verwendete aktuelle beste Route des betroffenen Verkehrs nicht, ändern insbesondere nicht den entsprechenden Eintrag in Routingtabellen (FIB (forwarding information base) ) und ersetzen keine über reguläre UPDATE Nachrichten gelernte Routen. Wie später auch die UPDATE Nachricht U2 löst damit die Ankündigung Ul Konvergenzprozesse aus. Ein entferntes autonomes System B, das später auf U2 reagieren und QoS-Verkehr umlegen wird, durchläuft einen Konvergenzprozess und lernt bereits jetzt die später verfügbaren Routen und insbesondere die sich später einstellende konvergente Route, auf die der Verkehr dann umgelegt wird. Nach einer angemessenen Zeitspanne und noch vor Ablauf des aus den Ankündigungen bekannten Zeitpunkts des Versendens von U2 reserviert das autonomes System B die für das Umlegen des betroffenen Verkehrs benötigten Ressourcen auf der aus den Ankündigungen gelernten, konvergenten, besten zukünftigen Route. Dafür wird eine entsprechende
Signalisierungsnachricht an den in der Ankündigung Ul genannten Ressourcemanager des autonomen Systems A gesandt. Um das zu ermöglichen, haben alle an der Weitergabe von angekündigten Routen beteiligten autonomen Systeme eine Route mit einem geeigneten Prefix der IP-Adresse des Ressourcenmanagers eingerichtet. Das heißt, die Signalisierungsnachricht an den Ressourcenmanager in dem autonomen System A läuft in der Regel bereits über den neuen besten Pfad. Wenn dann zum angekündigten Zeitpunkt die UPDATE Nachricht U2 gesendet wird, reagieren alle autonomen Systeme wie bisher, d.h. realisieren ein Routing für den betroffenen Verkehr entlang der neuen Route. Diejenigen autonomen Systeme, die aus der Ankündigungsphase schon wissen, dass sie Verkehr auf eine neue Routen umlegen, warten auf das Eintreffen der schon bekannten konvergenten Route. Erst dann ändern sie ihre Routingtabellen (FIBs: forwarding information bases) und geben eine entsprechende UPDATE Nachricht weiter.
Fig.l zeigt sieben autonome Systeme ASl, AS2, ..., AS7. An ASl sind zwei Netze angeschlossen, Netz Nl und Netz N2. Im Netz Nl sind die Endsysteme mit den IP-Adressen im Adressblock 10.10.10.0/24, d.h. 10.10.10.0 bis 10.10.10.255 erreichbar, im Netz N2 die Endsysteme mit den Adressen im
Adressblock 10.10.11.0/24, d.h. 10.10.11.0 bis 10.10.11.255. Dabei gibt 10.10.10.0/24 eine IP-Adresse, 10.10.10.0, und einen Maskenlänge, 24, an und steht für alle IP-Adressen, die in den ersten 24 Bit (Maskenlänge) mit der angegebenen Adresse 10.10.10.0 übereinstimmen, also 10.10.10.0 bis
10.10.10.255. In Fig. 1 dargestellt ist nur ein Teil der beteiligten Router, die Border-Router oder Randrouter, über die die autonomen Systeme miteinander verbunden sind: RlI, R12, R21, R22, R31, R32, R33, R41, R42, R51, R52, R61, R62, R71 und R72. Ebenfalls nur teilweise dargestellt sind die für das Ressourcenmanagement verantwortlichen Komponenten. Wie mit den Ressourcenmanagern RMlI, RM12, RM61 und RM62 beispielhaft angedeutet, ist hier insbesondere jedem Border- Router ein Ressourcenmanager zugeordnet.
Routen werden in diesem Beispiel in der Form (P, al, a2, ..., aN) dargestellt. Dabei beschreibt der Prefix P den Adressblock mit den erreichbaren Zieladressen und die folgende Sequenz al, a2, ..., aN die Sequenz der zu durchlaufenden autonomen Systeme über die der Verkehr die
Zieladressen aus P erreicht. Zum Beispiel ist (10.10.10.0/23, 4, 2, 1) eine Route von dem autonomen System AS6. Sie führt mit dem Adressblock 10.10.10.0/23 zu den Netzen Nl und N2. Die Zahlenfolge 4, 2, 1 steht für die Sequenz der autonomen Systeme: AS4, AS2, ASl, die den Verkehr von dem autonomen System AS6 zu den Netzen Nl und N2 weiterleiten. Angenommen, das autonome System AS6 nutzt die Route (10.10.10.0/23, 4, 2, 1) für den Verkehr zu den Zielnetzen Nl und N2, die Auslastung der Verbindung zwischen den Router R21 und RlI nähert sich der Kapazitätsgrenze und das autonome System ASl möchte ein Teil des Verkehrs auf andere Routen umlegen. Weiter wird angenommen, dass das autonome System ASl sich entscheidet, den Verkehr zum Netz N2 auf Routen über R12 umzulegen.
Nach dem bisherigen Verfahren, also im Rahmen des BGP
Protokolls ohne das neue erfindungsgemäße Verfahren, würde der Router RlI die über ihn erreichbaren Zieladressen mit einer UPDATE Nachricht auf 10.10.10.0/24 einschränken und der Router R12 mit einer UPDATE Nachricht die Erreichbarkeit von 10.10.11.0/24 bekannt geben. Das würde eine im Allgemeinen durchschnittlich dreiminütigen Konvergenzprozess einleiten, während dem die Dienstqualität für Verkehrsströme von dem autonomen System AS6 zu den Netzen Nl und N2 erheblich leidet und möglicherweise während des Konvergenzprozesses mehrfach Ressourcen auf unterschiedlichen Wegen zwischen den autonomen Systemen AS6 und ASl reserviert werden.
Nach dem neuen erfindungsgemäßen Verfahren sendet der Router R12 eine UPDATE Nachricht Ul an den Router R31, die eine Ankündigung der Route (10.10.11.0/24, 1) enthält. In Ul könnte stehen, dass diese Route in 10 Minuten mit einer weiteren UPDATE Nachricht verbindlich mitgeteilt wird. AS3 propagiert die angekündigte Route als (10.10.11.0/24, 3, 1) an die Router R41, R51 und R71. Das autonome System AS4 propagiert die angekündigte Route als (10.10.11.0/24, 4, 3, 1) an das autonome System AS6, obwohl der Router R42 schon (10.10.10.0/23, 4, 3, 1) an den Router R61 weitergegeben hat. Die Konvergenzphase ist in diesem Beispiel abgeschlossen, wenn (10.10.11.0/24, 4, 3, 1) über den Router R42, (10.10.11.0/24, 5, 3, 1) über den Router R52 und
(10.10.11.0/24, 7, 3, 1) über den Router R72 bei dem autonomen System AS6 angekommen sind und das autonome System AS6 die aus seiner Sicht beste Route ausgewählt hat. Hier wird angenommen, dass das autonome System AS6 sich für (10.10.11.0/24, 5, 3, 1) entscheidet, z.B. weil es sich im Sinne einer Metrik um die optimale Route handelt. Mit den angekündigten Routen erfährt das autonome System AS6 auch den von dem autonomen System ASl beabsichtigten
Umschaltzeitpunkt. Unter Berücksichtigung, dass die Uhren der autonomen Systeme ASl und AS6 nicht synchron laufen, wird das autonome System AS6 sein Ressourcemanagement rechtzeitig über seine Routenwahl informieren und den Ressourcenmanager RM62 veranlassen die benötigten Ressourcen auf der gewählten zukünftigen Route an den Ressourcenmanager RM12 zu signalisieren. Damit liegt die neue Route fest, und die erforderlichen Ressourcen sind schon bereitgestellt, wenn der Router R12 zum angekündigten Zeitpunkt eine weitere UPDATE Nachricht U2 mit der Route (10.10.11.0/24, 1) an den Router R31 sendet, diesmal als reguläre UPDATE Nachricht. In einer nicht vorher bestimmbaren Reihenfolge werden ausgelöst durch die U2 UPDATE Nachrichten mit den Routen (10.10.11.0/24, 4, 3, 1), (10.10.11.0/24, 5, 3, 1) und (10.10.11.0/24, 7, 3, 1) bei dem autonomen System AS6 eintreffen. Das autonome System AS6 kennt die neue konvergente Route schon und wird jetzt solange warten, bis die UPDATE Nachricht mit der Route (10.10.11.0/24, 5, 3, 1) eintrifft. Dann wird das autonome System AS6 sein Routing anpassen und den Verkehr zu N2 auf den neuen Weg legen, der zu diesem Zeitpunkt schon durchgängig steht, den konvergenten Zustand darstellt und die erforderlichen Ressourcen bereithält. Ohne wesentliche Beeinträchtigung der Dienstgüte wird damit der Verkehr auf die neue Route umgestellt (bis auf mögliche Überschneidungen von Verkehr auf der neuen Strecke und noch auf der alten
Strecke laufenden Verkehrs, der zum Zeitpunkt des Umroutens sein Ziel noch nicht erreicht hat) . Anschließend wird der Ressourcenmanager RM61 die auf der alten Route über die autonomen Systeme AS4, AS2 und ASl reservierten Ressourcen anpassen, d.h. die durch die Verkehrsumlegung nicht mehr benötigten Ressourcen freigeben. Das autonome Systeme AS6 verfährt dabei nach dem in Fig. 2 und Fig. 3 gezeigten Ablaufdiagramm. Zur Vereinfachung ist hier angenommen, dass ein UPDATE nur eine bekannt gegebene Route R mit Prefix P enthält (Schritt 101) . Eine Erweiterung für UPDATE Nachrichten, die mehrere Routen bekannt geben, ist für den Fachmann trivial. Die Schritte 102, 104, 105, 107, 108 und 109 entsprechen der im RFC1771 beschriebenen Verarbeitung bekannt gegebener Routen. Im Schritt 106 werden in diesem Verlauf Routenankündigungen herausgefiltert, die zukünftig beste Route beschreiben, und in einer neuen
Datenbank für angekündigte Routen, Pen-RIB (Pen für Pending (englisch für bevorstehend) ) , gespeichert (Schritt 123) . Ist R die erste derartige Routenankündigung für den Prefix P (kein Eintrag in Pen-RIB) wird ein Zeitgeber gestartet (Schritt 121 und 122) . Aus der Routenankündigung R wird eine Route R* generiert, die bis auf den Prefix P* mit R identisch ist (Schritt 124) . P* ist der mit R gegebene Prefix des zuständigen Ressourcemanagers für Reservierungen auf der angekündigten Route, im Beispiel ein Prefix für eine Adresse von RM12 in ASl. R* wird nun statt der Routenankündigung in Loc-RIB eingetragen und aktiviert (Schritt 125) . Angekündigte Routen, die aufgrund der in Pen-RIB eingetragenen Routenankündigungen erwartet werden, werden im Schritt 103 ausgefiltert und gesondert behandelt. Sie werden in die Datenbank Pen-RIB eingetragen (Schritt 131) . Mit dem ersten solchen Eintrag wird ein Zeitgeber gestartet (Schritt 132 und 133) . Entspricht die Route R der in Pen-RIB enthaltenen neuen besten Route, werden alle in Pen-RIB für den Prefix P zwischengespeicherten Routen verarbeitet und alle Einträge für den Prefix P in Pen-RIB gelöscht (Schritt
134, 135 und 136) . Die Verarbeitung im Schritt 135 entspricht der der Schritte 104, 105, 107, 108 und 109.
Läuft ein in Schritt 122 aufgezogener Timer aus (Schritt 201) wird das Ressourcenmanagement über die bevorstehende Routenänderung informiert um eine entsprechende
Ressourcenreservierung zu veranlassen (Schritt 202) . Läuft ein in Schritt 133 aufgezogener Timer aus (Schritt 301) , wird davon ausgegangen, dass die in Pen-RIB gespeicherte neue beste Route ihre Gültigkeit verloren hat. Es wird geprüft, ob es Einträge für den Prefix P in Pen-RIB gibt (Schritt 302) . Fall ja, werden alle in Pen-RIB zum Prefix P zwischengespeicherten Routen verarbeitet (Schritt 303) und in Pen-RIB gelöscht (Schritt 304) . Weiter wird das Ressourcenmanagement über die Änderung informiert (Schritt 305) .
Ist davon auszugehen, dass von mehreren autonomen Systemen initiierte Routenänderungen für den selben Prefix in Pen-RIB gehalten werden müssen, dann müssen die Eintragungen in Pen- RIB nach Prefix und einer Identifikation des Absenders der ursprünglichen Ankündigung (ASl oder Router R12 im Beispiel) erfolgen. Dazu muss Routenänderungsnachrichten gegebenenfalls ein geeigneter Wert für diese Identifikation mitgegeben werden, z.B. eine AS-Nummer oder eine IP-Adresse eines Randrouters .

Claims

Patentansprüche
1. Verfahren zur Festsetzung einer Route für das Routen von Verkehr, bei dem - an ein Netzelement (R62) eines Netzes (AS6) eine
Routenankündigungsnachricht zur Ankündigung einer Route gesendet wird, und
- zeitverzögert zu der Routenankündigungsnachricht das Netzelement (R62) durch ein Ereignis veranlasst wird, Verkehr nach Maßgabe der angekündigten Route zu routen.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Festsetzung der Route für das Routen von Verkehr im Rahmen eines Inter-Domänen Routings erfolgt.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Festsetzung der Route mit Hilfe des BGP (Border Gateway Protocol) Protokolls erfolgt.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei Ankündigung von mehreren Routen zu demselben Ziel (N2) vor Eintreten des Ereignisses eine Auswahl einer im Sinne einer Metrik optimalen Route vorgenommen wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ereignis in dem Senden einer Routenaktivierungsnachricht besteht.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Routenaktivierungsnachricht durch eine UPDATE Nachricht gegeben ist.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach der Ankündigung der Route eine auf die Route bezogene
Ressourcenreservierung eingeleitet wird.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass eine Ressourcenreservierungsnachricht durch eine Ressourcenmanagementinstanz (RM62) des Netzelements (R62) zur Ressourcenreservierung entlang der angekündigten Route gesendet wird.
9. Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass eine Adresse einer für die Ressourcenreservierung zuständigen Ressourcenmanagementinstanz mittels der
Routenankündigungsnachricht dem Netzelement (R62) mitgeteilt wird.
10. Verfahren nach Anspruch 8 oder 9, dadurch gekennzeichnet, dass
Ressourcenreservierungsnachrichten entlang der angekündigten Route zwecks Ressourcenreservierung für die Benutzung der Route übertragen werden.
11. Verfahren nach einem der Ansprüche 8 bis 10, dadurch gekennzeichnet, dass dem Netzelement (R62) eine erfolgreiche Ressourcenreservierung bestätigt wird.
12. Verfahren nach einem der Ansprüche 8 bis 11, dadurch gekennzeichnet, dass bei nicht erfolgreicher Ressourcenreservierung trotz
Eintreten des Ereignisses keine Festsetzung einer Route für das Routen von Verkehr vorgenommen wird.
13. Verfahren nach Anspruch 5 und einem der Ansprüche 8 bis
11, dadurch gekennzeichnet, dass bei nicht erfolgreicher Ressourcenreservierung keine Routenaktivierungsnachricht an das Netzelement (R62) gesendet wird.
14. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht eine Kennzeichnung umfasst, durch welche sie als Routenankündigungsnachricht identifizierbar ist.
15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht eine Information über den Zeitpunkt des Eintritts des Ereignisses umfasst.
16. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht zumindest eine Adresse einer für die Reservierung einer Ressource zwecks Übertragung entlang der Route zuständigen Ressourcenmanagementinstanz umfasst.
17. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Routenankündigungsnachricht im Wesentlichen die Form einer UPDATE Nachricht hat.
18. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der über die angekündigte Route zu übertragende Verkehr zumindest teilweise unter Einhaltung von Dienstgütemerkmalen zu übertragen ist.
19. Netzelement (R62) mit Mitteln zu Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 18.
EP05777989A 2004-07-30 2005-07-29 Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz Withdrawn EP1774730A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004037024A DE102004037024B4 (de) 2004-07-30 2004-07-30 Verfahren und Netzelement für ein die Dienstgüte erhaltendes Umrouten von Verkehr in Netzen mit langsamer Routenkonvergenz
PCT/EP2005/053718 WO2006013191A1 (de) 2004-07-30 2005-07-29 Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz

Publications (1)

Publication Number Publication Date
EP1774730A1 true EP1774730A1 (de) 2007-04-18

Family

ID=35115858

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05777989A Withdrawn EP1774730A1 (de) 2004-07-30 2005-07-29 Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz

Country Status (5)

Country Link
US (1) US20080098127A1 (de)
EP (1) EP1774730A1 (de)
CN (1) CN1993942A (de)
DE (1) DE102004037024B4 (de)
WO (1) WO2006013191A1 (de)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8166197B2 (en) * 2005-10-25 2012-04-24 Oracle International Corporation Multipath routing process
DE102006015239B3 (de) * 2006-03-30 2007-08-23 Siemens Ag Netzzugangssteuerung mit zusätzlicher Verkehrsklasse in einem Kommunikationsnetz
US20070233885A1 (en) * 2006-03-31 2007-10-04 Buskens Richard W Architectures for assuring the inter-domain transport of QoS sensitive information
EP1940091B1 (de) * 2006-12-27 2009-10-07 Nec Corporation Autonomes Netzwerk, Netzknotenvorrichtung, Netzwerkredundanzverfahren und Aufzeichnungsmittel
US8036141B2 (en) * 2008-08-15 2011-10-11 At&T Intellectual Property I, L.P Apparatus and method for managing a network
US8826271B2 (en) 2010-04-28 2014-09-02 Cavium, Inc. Method and apparatus for a virtual system on chip
US20120124238A1 (en) * 2010-11-12 2012-05-17 Alcatel-Lucent Bell N.V. Prioritization of routing information updates
US9424144B2 (en) 2011-07-27 2016-08-23 Microsoft Technology Licensing, Llc Virtual machine migration to minimize packet loss in virtualized network
US9531642B1 (en) 2014-09-30 2016-12-27 Amazon Technologies, Inc. Distributing routing updates according to a synchronous mode
US9699068B1 (en) * 2014-09-30 2017-07-04 Amazon Technologies, Inc. Distributing routing updates according to a decay mode
US9806985B2 (en) * 2015-03-02 2017-10-31 Cisco Technology, Inc. Symmetric routing enforcement
CN111030929A (zh) * 2015-10-16 2020-04-17 华为技术有限公司 一种路由处理方法、设备及系统
US10235211B2 (en) * 2016-04-22 2019-03-19 Cavium, Llc Method and apparatus for dynamic virtual system on chip
US11909763B2 (en) * 2021-04-07 2024-02-20 Cisco Technology, Inc. BGP blackhole and hijack mitigation
US11843533B2 (en) * 2022-02-28 2023-12-12 Microsoft Technology Licensing, Llc End-to-end performance aware traffic engineering for internet peering

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6658469B1 (en) * 1998-12-18 2003-12-02 Microsoft Corporation Method and system for switching between network transport providers
JP2001217839A (ja) * 2000-01-31 2001-08-10 Fujitsu Ltd ノード装置
US7234001B2 (en) * 2000-12-20 2007-06-19 Nortel Networks Limited Dormant backup link for OSPF network protection
US6792091B2 (en) * 2002-02-22 2004-09-14 Marc S. Lemchen Network-based intercom system and method for simulating a hardware based dedicated intercom system
US7286468B2 (en) * 2002-11-12 2007-10-23 Cisco Technology, Inc. Routing system and method for synchronizing a routing system with peers after failover
US8161152B2 (en) * 2003-03-18 2012-04-17 Renesys Corporation Methods and systems for monitoring network routing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006013191A1 *

Also Published As

Publication number Publication date
CN1993942A (zh) 2007-07-04
DE102004037024A1 (de) 2006-03-23
WO2006013191A1 (de) 2006-02-09
US20080098127A1 (en) 2008-04-24
DE102004037024B4 (de) 2006-07-13

Similar Documents

Publication Publication Date Title
EP1774730A1 (de) Verfahren und netzelement für ein die dienstgüte erhaltendes umrouten von verkehr in netzen mit langsamer routenkonvergenz
DE60026238T2 (de) Auf vorspezifizierter Dienstgüte basierender Verbindungsaufbau durch ein Kommunikationsnetz
DE69808753T2 (de) Mehrfachübertragungsvermittlung und -verfahren
DE69829203T2 (de) Paketnetzwerk
DE60030122T2 (de) Implementation eines effizienten internetdienstes für verknüpfte satellitnetze
DE60202491T2 (de) Verfahren und System zum Steuern eines Kommunikationsnetzes und eines im Netz angewandten Routers
EP0784894B1 (de) Verfahren und anordnung zur adressierung von teilnehmern in einem aus mindestens zwei segmenten bestehenden netzwerk
EP2135404B1 (de) Verfahren zum betreiben eines nach art des mesh, insbesondere gemäss dem standard ieee 802.11s, aus einer vielzahl von netzwerkknoten gebildeten netzwerks
EP1405540A1 (de) Verfahren zum durchführen eines qos-orientierten handoffs zwischen einem ersten und einem zweiten ip-basierten, insbesondere mobilen ipv6-basierten kommunikationspfad zwischen einem mobile node (mn) und einem correspondent node (cn)
EP2055056A1 (de) Verfahren und netzwerkknoten zum routen von datenpaketen in kommunikationsnetzen
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
DE102005016587A1 (de) Verfahren zum Bilden einer gemeinsamen Kommunikationssitzung, Verfahren zum Bilden einer ersten Kommunikationssitzung und einer zweiten Kommunikationssitzung aus einer gemeinsamen Kommunikationssitzung und Kommunikationssitzungs-Steuerungs-Server
DE60037914T2 (de) Multicasting von Daten in einem mobilen IP-Kommunikationsnetz
WO2018162071A1 (de) Verfahren und vorrichtung zur modularen lenkung eines avb-streams
DE102006027708B3 (de) Verfahren zur Optimierung einer Kommunikationsverbindung in einem paketvermittelten Sprachdatennetzwerk
DE10238291A1 (de) Effizientes Intra-Domain Routing in Paketnetzen
DE60022057T2 (de) Verfahren um im multi-protocol label switching schleifen zu vermeiden
EP2847966B1 (de) Verfahren zur übertragung von daten in einem paketorientierten kommunikationsnetzwerk, entsprechendes system und entsprechendes computerprogrammprodukt
EP1757049A1 (de) Verfahren zur ressourcen-reservierung für ein inter-domain-routing mit dienstgütemerkmalen
DE102004058927B3 (de) Aggregation der inter-domain Ressourcen-Signalisierung
EP2321997B1 (de) Verfahren zum austausch von routing-nachrichten in einem drahtlosen vermaschten kommunikationsnetz
EP3664510A1 (de) Wechsel des datenübertragungsweges ohne verlust von datenpaketen
WO2005027435A1 (de) Verfahren zur optimierten deaktivierung von inter-domain routen
EP3672163A1 (de) Verfahren zur datenkommunikation, kommunikationsgerät, computerprogramm und computerlesbares medium
DE10047131B4 (de) Verfahren zum Betreiben eines Zugangsnetzes

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060823

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20070731

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS S.P.A.

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NOKIA SIEMENS NETWORKS GMBH & CO. KG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20091120