WO2006045752A1

WO2006045752A1 - Inter-domain routing for quality of service traffic

Info

Publication number: WO2006045752A1
Application number: PCT/EP2005/055433
Authority: WO
Inventors: Thomas Engel; Thomas Schwabe
Original assignee: Siemens Aktiengesellschaft
Priority date: 2004-10-29
Filing date: 2005-10-20
Publication date: 2006-05-04

Abstract

The invention relates to inter-domain routing with QoS (Quality of Service) characteristics. Route indication messages used in the framework of inter-domain routing are provided with additional information or an additional attribute confirming whether the indicated route is suitable for QoS traffic or not. In this way, the domains of a network interconnection or the Internet are able to select suitable inter-domain routes for the routing of QoS traffic. Inter-domain routing which fulfils quality of service criteria is thus rendered possible by the identification of the suitable routes.

Description

description

Inter-domain routing for Quality of Service traffic

The invention relates to a method and a router for the selection of routes for a quality of service (QoS) domain routing.

One of the currently central developments in the field of networks is the further development of conventional data networks for so-called real-time traffic. Voice, audio, and video information is to be gen in real time with a guaranteed quality of service übertra ^¬. In this context, QoS (Quality of Service) is used instead of quality of service.

The most important example of a data network technology to be extended for the transmission of QoS traffic is the networks based on the IP (Internet Protocol) protocol. In the future, IP networks should also support applications that transmit voice, video and data streams, which requires fast and reliable transport of IP packets. For this, future IP networks, in addition to the tradi¬ tional "best effort" service (BE) service, new Übertra ^¬ supply services provide that provide the required bandwidth throughout the transport and IP packets wrestle with ge, barely fluctuating delay and very low packet loss rates reliably transmitted to the receiver. These new QoS services are referred to as QoS traffic in the following QoS services and the traffic they transport; transported via BE services

Traffic is called BE traffic. Furthermore, an IP network with QoS support NGN (Next Generation Net¬ work) and an IP network without QoS support BE network are mentioned below.

Today's Internet is an amalgamation of a growing number of individual IP networks, so-called autonomous systems (AS) or domains, from different organizations managed and controlled. At present, the Internet consists of more than 15,000 autonomous systems. Similarly, in the future, NGNs will be combined into a network and QoS services will be offered across networks. A composite of interconnected NGNs is called an NGN cluster.

At least in a transitional phase IP networks with and oh ^¬ ne QoS support co-exist. Both NGNs and BE networks (BE networks are the current Internet) are then connected to the Internet and support conventional data exchange in the form of BE traffic. In addition, growing NGN clusters, which are likely to be included in the Internet, will be created in which network-overlapping QoS services can additionally be used (see FIG. 1).

For cross-network routing, so-called inter-domain routing, the BGP (Border Gateway Protocol, defined in [RFC1771]) protocol is currently used. The BGP protocol regulates the cross-network forwarding of IP packets across the boundaries of individual IP networks, ie which paths take IP packets if they have to traverse more than one autonomous system. For this interplay of autonomous systems on the Internet, adjacent border or edge routers of adjacent IP networks establish BGP peering sessions and exchange UPDATE routing information. By means of the BGP protocol, a network or an autonomous system learns which IP addresses can be reached via which routes and to which neighboring network it can forward corresponding traffic. Conversely, a network using BGP IP addresses of the connected end systems known so ent ^¬ speaking traffic to it can be passed. Inter-domain routes announced by the BGP protocol are cross-network routes at the level of autonomous systems (AS) and are encoded as sequences of AS numbers. For this purpose, autonomous systems are assigned unique AS numbers. The BGP protocol can be UPDATE messages new routes to announce and reindeer announced routes for invalid erklä ^¬. A route change (new route, invalid route) mush ^¬ tet to ignore generally have more FIX messages from network to network over large parts of the Internet out. Wei ^¬ ter remote networks generally obtained in several ways more UPDATE messages and see different routes to the same destination from which they select the best from their perspective route.

Technically, the provision of QoS services in the inter-domain area is expected to build on DiffServ, the IETF's "Differentiated Service" model ([RFC2474], [RFC2475]), and cross-network collaborative resource management systems. Different QoS services will support different values (statistical guarantees) of the performance parameters delay, jitter and packet loss rate, and different types of traffic. For the provision and management of the resources required for QoS services, the

Resource management systems of each NGNs on signaling protocols, such as the BGRP (Border Gateway Reservation Protocol) protocol work together. Such resource management systems are not yet used in the current Internet, but intensive work is being done on them (see, eg, Pan, P., E. Hahne, H. Schulzrinne: "BGRP: Sink-Tree-Based Aggregation for Inter-Domain Reservations", Journal of Communications and Networks, Vol. 2, No. 2, pp. 157-167, http://www.cs.columbia.edu/~pingpan/papers/bgrp.pdf, June

2000, Teitelbaum, B., "QBone Bandwidth Broker Architecture", Work In Progress, http://qbone.internet2.edu/bb/bboutline2.html, 2000] and "Next Steps in Signaling (nsis)", IETF working group, r_tτ.p: //www.ietf.org/ntml .char: .ers / nsis ^™ cr.arter.ntnl) According to the published proposals

Resource management systems basically work as follows. The resource management sends by means of a

Signaling protocol Reservation requests along the routes provided by the BGP protocol to reserve the resources needed for QoS traffic between sender and receiver. If all participating networks agree (availability of resources), a positive response is sent back to the initiator and appropriate reservations of resources are made. Reservation and traffic follow the routes selected by the BGP protocol. The quality of service assured to QoS traffic is achieved only if the BGP protocol for QoS traffic only selects routes within NGN clusters. It is therefore necessary to use NGN routes, i. NGN connecting routes, which lead only over NGNs and not over BE nets.

It is an object of the invention to specify a method which makes it possible to select routes for inter-domain routing while maintaining QoS features.

The invention is based on the observation that routing along an inter-domain route in compliance with QoS (quality of service) features or quality of service features is only possible if the individual domains along the route support QoS routing. For selecting a route that supports routing in compliance with quality of service characteristics or

Therefore, it is necessary to know whether QoS features located along this route can route QoS traffic with the required quality of service features. A Routing domain is a network management or network Orga ^¬ tion area, which is (usually consisting of one or meh¬ reren merged networks) in Zuständig¬ keitsbereich a service provider and a uniform ches intra-domain routing has. This Netzverwaltungsbe can ^¬ rich exchange with one or more other Netzverwatungsbe- rich messages or data and is often based on the English with domain (domain) or as an auto ^¬ nomes system (autonomous system), respectively. Within such a domain, the operator has the option of enabling or supporting the routing of QoS traffic by means of QoS mechanisms. In IP networks that support QoS routing, one often speaks of NGNs (New Generation Networks).

The invention is based on the idea by means of inter-domain route announcement messages, ie messages announcing new or changed inter-domain routes, also to indicate whether the respective route is QoS-capable, ie allow the domains along the route QoS routing. According to the invention, an inter-domain route ei ^¬ ner second mitge ^¬ shared by means of a route announcement message, which is specified in the route announcement message, whether along the route, ie by the forming the route domains, a routing of QoS traffic supported by a QoS feature. The term QoS

Feature to be understood that it includes both a general ^¬ can call my property, such as for example the fact that it is NGNs can be given as well as special Para ^¬ meters, which are for a QoS routing required lent, For example, delay times, loss rates or jitter. The route announcement message can also multiply ^¬ re information regarding the QoS capability of the domains along the route included. Preferably, the information is in the form of an attribute in the route announcement message, which is, for example, an UPDATE message of the BGB protocol.

An inter-domain route, for example, by the border-gateway protocol (BGP) propagated between domains and ge ^¬ will learn not QoS-enabled route is then more once it contains a domain that does not support QoS routing. A QoS-enabled route to which a non-QoS-enabled domain is attached must subsequently be propagated or advertised as a non-QoS-capable route. According to developments of the subject invention, three approaches are proposed ^¬ how this requirement can be considered:

The first, preferred procedure is that a QoS-capable domain or an NGN, which receives a route announcement ^¬ message from a non-QoS-capable network in which ei¬ ne on this non-QoS-capable domain leading route is mitge ^¬ shares that changes information regarding the QoS capability of the route such that the route is designated as non-QoS capable if the information obtained by the non-QoS capable network still indicates the route as QoS enabled. When propagating or redistribution of routes the information or the attribute is changed so the QoS-enabled networks, which change triggered by the receipt of a route announcement message with a ausgewie as QoS-enabled ^¬ Senen route from a non-QoS-enabled domain becomes. This approach has the advantage that the Informa ^¬ tion or attribute on the QoS capability of the route must be interpreted only by QoS-enabled domains. Non-QoS-enabled domains that traditionally do not know this information as well this or that attribute, it can ignorie ^¬ ren. A second possibility is that QoS-enabled Domae ^¬ NEN receiving a route advertisement message, in which the information the mentioned route as a QoS-capable does ^¬, then change this information when the route by a route announcement message to a non-QoS -able

Domain is communicated. In contrast to the first possibility, therefore, the information identifying the route as QoS-capable is not changed after transmission of a route announcement message by a non-QoS-capable domain, but before transmission to a non-QoS-capable domain by an NGN. Even with this approach, the information is not used up by non-QoS-enabled domains read or interpreted to ^¬ the. In contrast to the first variant, in further ^¬ the route reproducing discriminated whether the domain to which the route is passed, QoS-enabled or not. In passing on several adjacent domains, if necessary, capable of QoS and non-QoS-enabled domains is Routenankündigungsnach ^¬ judge regarding with different information. Passed the QoS capability.

In a third possible form of implementation, the information or the attribute is changed by a non-QoS-capable domain, namely when it is notified of a QoS-capable domain of a QoS-capable route and further propagates it to other domains.

The three approaches can also be combined with one another and / or used simultaneously.

As a result of the invention, routes propagated between domains are identified as QoS-capable or not QoS-capable, so that the domains or dedicated routers of the domains select a route in accordance with the information about the QoS capability, eg by discarding or disregarding QoS-enabled routes for routing QoS traffic. Different routes for QoS traffic and for non-QoS traffic can also be provided by domains or by their routers, namely, for example, if the route which is optimal in terms of the metric is not QoS-capable. It then makes sense to use the optimal non-QoS-capable and QoS-capable routes for the routing in the sense of the metric used.

The transmitted through the route announcement message Infor ^¬ mation about the QoS capability of a route can be combined with other criteria for QoS ability to identify suitable for QoS traffic routes. Further criteria can be derived, for example, from metric information learned using the routing protocol, for example the number of hops. A route advertised as a QoS-enabled route is then used, for example, only as such for the routing of QoS traffic, if the number of hops does not exceed an upper limit.

By means of the method according to the invention, the inter-domain routing protocol, eg BGP, can decide whether a route is capable of carrying QoS traffic. The routing protocol can thus take into account the requirements of QoS traffic. So that QoS traffic intra ^¬ is half-routed from QoS-enabled domains is and QoS traffic gets the assured quality of service is ensured.

Thus, the new method allows for the provision of QoS services via individual domains away by services QoS lower it netzübergrei ^¬ Fende by an appropriate route selection supports

The inventive method allows the resources Manage ^¬ ment to decide whether a reasonable passed in a resource request destination using a QoS route is reachable and ge ^¬ take if necessary, if no QoS route is available, ge ^¬ suitable measures (eg the participant inform and reject the request). Without such a check, a resource request may possibly pass unnoticed networks without QoS support (with indirect addressing of the resource management of the participating networks similar to RSVP) and the subscriber is guaranteed a quality of service that is not consistently supported.

The subject of the invention likewise comprises a router with means by carrying out a method according to the invention. These means are given for example by the method implementing software means.

In the following, the subject invention is explained in more detail in the context of an embodiment with reference to figures. Show it

1 shows a network of autonomous systems with clusters of NGNs.

Figure 2 shows the network of Figure 1, in addition

Edge routers are shown, via the autonomous systems exchange route announcement messages.

1 shows a network of IP networks or autonomous systems in which the invention is used. Inter-domain Routes are communicated using the BGP protocol. OF INVENTION ^¬ BGP protocol is introduced into UPDATE messages of a new attribute for the labeling of NGN QoS route or routes according dung. It is an optional, transitive attribute that is set as follows:

(i) A NGN connected to a BE network ("best effort" network that is not QoS capable) sets the attribute to NO_NGN_ROUTE in all routes received from BE networks, ie the route becomes non-QoS enabled marked.

(ii) An NGN announcing a route to self-managed IP addresses that qualify as endpoints of NGN routes sets the attribute to NGN_ROUTE, i.e., the route is marked QoS-enabled. (iü) An NGN receiving a route from an attached NGN does not change the value of the attribute.

If the attribute is set according to the rules i to iii, then by evaluating the new attribute in each NGN, the BGP protocol is able to distinguish between NGN routes and routes in question for QoS traffic, which are at least partly via BE networks, so-called BE routes. Thus, in the course of a route determination by means of the BGP protocol for IP addresses of end systems connected to NGNs, NGN routes can be selected by excluding BE routes from the selection.

Optionally, rules 3.i to 3.iii can be supplemented by the following rule, which can also be used as an alternative to rule 3.i:

(iv) If an NGN sends a route to a BE network, then the attribute for labeling NGN routes becomes the value NO_NGN_ROUTE set.

If no NGN route can be found for a prefix (IP address ranges are managed by BGP in the form of prefixes) because only BE routes are available, then one of the available BE routes can be selected and used for BE traffic ¬ det.

Furthermore, the resource management according to the invention can query via a suitable interface to the BGP protocol whether a route for QoS traffic is available for a specific destination address. Or the BGP protocol can reverse the resource management is a table of destination address ver ^¬ fügbaren NGN routes for QoS traffic over such interfaces provide location and the table for route changes fit an¬.

Optionally, in NGNs for QoS traffic and for BE traffic, different routes may be chosen, e.g. by routing the differentiated services codepoint (DSCP), which according to the DiffServ model governs the distinction of IP packets into QoS and BE packets.

Optionally, instead of the pure subdivision into NGN and BE routes, NGN routes may similarly be assigned further attributes relevant to QoS traffic (e.g., average and maximum end-to-end delay).

Fig. 1 shows how the Internet might look in the future. In addition to BE networks, ASl to AS7 (AS: autonomous system), it also contains connected NGNs, NGNlI to NGN17 and NGN21 to NGN23. The NGNs form two NGN clusters, that is, connected subnetworks consisting only of NGNs: NGN clusters 1 consisting of NGNlI to NGN17 and NGN cluster 2 consisting of NGN21 to NGN23.

FIG. 2 shows the same section from a future internet as FIG. 1, but supplemented by the two subscriber networks N1 and N2 and a part of the border routers R21, R22, R51,..., R231. The networks N1 and N2 connect the participants with IP addresses with prefix 10.10.10.0/24 or 20.20.20.0/24 with NGN14 or NGN23. In this case, the prefix A / M, consisting of an IP address A and a mask length M, denotes the IP adresses which match the address A in the first M bits, eg 10.10.10.0/24 stands for the IP Addresses: 10.10.10.0, 10.10.10.1, ..., 10.10.10.255. Routes are represented here in the form (P, al, a2, ..., aN). In this case, P is a prefix P, which describes the address block with the achievable destination addresses, and al, a2,..., AN ei ^¬ ne sequence of autonomous systems, which are traversed in the given order. For example, (10.10.10.0/24, 12, 13, 14) is a route that learns router rill from NGNIl via router R121 from NGN12. It leads from NGNlI via NGN12, NGN13 and NGN14 to the network Nl and applies to subscribers with IP addresses with prefix 10.10.10.0/24.

Let's say that Router Rill of NGNlI learns the two routes (10.10.10.0/24, 12, 13, 14) and (10.10.10.0/24, 6, 5, 14). Both lead to the same destination: 10.10.10.0/24, but only one is suitable for QoS traffic. If the NGNs use the above-described procedure, then both routes contain the new attribute. There will be the value NGN_ROUTE for the route (10.10.10.0/24, 12, 13, 14): NGNl4 is an NGN and becomes the route (0.10.10.0/24, 14, NGN_ROUTE) to router R132 after rule ii and send router R51. The value of the new attribute was appended to the AS path. NGN13 and NGN12 will be the Do not change attribute according to rule iii, as you will learn a route from an NGN via R132 or R122. Therefore Rill of R121 receives the route (0.10.10.0/24, 12, 13, 14, NGN_ROUTE).

The new attribute is a transitive, optional attribute which has no significance for BE networks (unless the optional rule iv is additionally used). Therefore, AS5 and AS6 will not change the value, and Router Rill will learn from router R61 the route (0.10.10.0/24, 6, 5, 14, NGN_ROUTE). Since Router Rill receives this route from a BE network, Router Rill will set the attribute to NO_NGN_ROUTE according to rule i and process the route (0.10.10.0/24, 6, 5, 14, NO_NGN_ROUTE). Now Rill knows the two routes (0.10.10.0/24, 12, 13, 14,

NGN_ROUTE) and (0.10.10.0/24, 6, 5, 14, NO_NGN_ROUTE) and can select the NGN route for QoS traffic.

Similarly, router R221 in NGN22 will learn that 20.20.20.0/24 can be reached via a route suitable for QoS traffic. Router R231 gives router R212 the rule according to rule ii

(20.20.20.0/24, 23, NGN_ROUTE). The routers R212, R213 and R221 attribute to rule iii unchanged sen ^¬ read.

However, router R221 will not learn any NGN route for prefix 10.10.10.0/24. Router R142 will send the route (10.10.10.0/24, 14, NGN_ROUTE) to router R51 under rule ii. Router R211, since BE networks do not change the attribute, receives the route (10.10.10.0/24, 2, 5, 14, NGN_ROUTE) from router R21. However, according to rule i, router R211 will change the attribute and further process the route (10.10.10.0/24, 2, 5, 14, NO_NGN_ROUTE). Router R213 will forward the route (10.10.10.0/24, 21, 2, 5, 14, NO_NGN_ROUTE) to router R221. The latter will not change the attribute of the route, which was received by a NGN, according to rule iii and now knows the correctly classified route (10.10.10.0/24, 21, 2, 5, 14, NO_NGN_ROUTE).

Optionally, rule iv can additionally be used. These additional to ^¬ rule does not change the result. In particular, those who learn ^¬ in the example router Rill and routers R221 then correctly classified routes, only non-NGN routes are then previously marked as such.

Claims

claims

1. A method for selecting routes for a quality of service (QoS) inter-domain routing, characterized in that

- An inter-domain route by means of a route announcement ^¬ message by a first domain of a second domain mitge ^¬ shares, and

is specified by means of an information contained in the route announcement message, whether along the route

Routing of QoS traffic is supported while maintaining a QoS feature.

2. The method according to claim 1, characterized in that the information in the form of an attribute in the object supply Routenankündi ^¬ is included.

3. The method according to claim 1 or 2, characterized in that

- the first domain does not support QoS routing,

- the second domain supports QoS routing,

the information characterizes the inter-domain route as a routing of QoS traffic in compliance with the QoS feature,

- the information for the retransmission of the route by means of route announcement messages by the second domain is geän¬ changed, and

- by the second domain, the route of a third domain with- is telling means of a route advertisement message, wherein the route announcement message includes information as not processing the route routing of QoS traffic under Einhal ^¬ the QoS characteristic features supportive.

4. The method according to any one of claims 1 to 3, characterized in that - the first domain supports QoS routing,

- the second domain does not support QoS routing,

- the inter-domain route by a route announcement ^¬ message of the first domain is notified, the infor- mation the inter-domain route as a routing of QoS services respecting the QoS feature supportive features,

the information for the communication of the route to the second domain is changed by the first domain, and

the first domain informs the route of the second domain by means of a route announcement message, the

Route Announcement message contains information that identifies the route as not a routing of QoS traffic in compliance with the QoS feature supportive.

5. The method according to any one of claims 1 to 4, characterized in that

- the first domain supports QoS routing,

- the second domain does not support QoS routing,

- the information for the retransmission of the route is changed geän¬ means of Route Advertisement messages by the second domain, and - by the second domain, the route of a third domain with ^¬ means of a route announcement message notifying, wherein the route announcement message includes information, which is not the route as a routing of QoS traffic under Einhal ^¬ processing of QoS feature identifies supportive.

6. The method according to any one of the preceding claims 3 to 6, characterized in that the route announcement message contains a plurality of transfer quality characteristics related information, which are changed according to claim 3, 4 or 5 in Weiterlei ^¬ th of route announcement messages.

7. The method according to any one of the preceding claims, characterized in that the route announcement message is an UPDATE message of the BGP protocol.

8. The method according to any one of the preceding claims, characterized in that

in a router of a domain, a selection of an inter-domain route is made from inter-domain routes communicated via route announcement messages, and

- That this selection takes place in accordance with the information as to whether along the route a routing of QoS traffic while maintaining the QoS feature is supported.

9. The method according to claim 8, characterized in that

- In the router different routes for QoS traffic and non-QoS traffic can be specified.

10. The method according to any one of the preceding claims, characterized in that information contained in the second domain sent Routenanfolgungnach¬ information on the support of QoS routing on the announced route to the resource management of the domain is made available.

11. The method according to claim 10, characterized in that the information is transmitted to the resource management or kept retrievable by the resource management.

12. Router with means for carrying out a method according to one of claims 1 to 11.