EP2014031A1 - Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants - Google Patents

Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants

Info

Publication number
EP2014031A1
EP2014031A1 EP07731924A EP07731924A EP2014031A1 EP 2014031 A1 EP2014031 A1 EP 2014031A1 EP 07731924 A EP07731924 A EP 07731924A EP 07731924 A EP07731924 A EP 07731924A EP 2014031 A1 EP2014031 A1 EP 2014031A1
Authority
EP
European Patent Office
Prior art keywords
telephony
route
destination
list
autonomous system
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
EP07731924A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of EP2014031A1 publication Critical patent/EP2014031A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/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/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment

Definitions

  • a method of selecting a telephony route within an IP telephony domain, corresponding device and computer program is a method of selecting a telephony route within an IP telephony domain, corresponding device and computer program.
  • Telephony is understood to mean both conventional telephony services or integrating advanced services such as video telephony or the synchronous digital data transfer service.
  • the present invention relates more particularly to the exchange of information to allow the synchronization between the service layer (that is to say that dealing with call routing) and the network layer (that is to say that the occupying IP datagram transfer) for routing information flows between IP telephony domains.
  • IP network is the backbone adopted by operators to pool their heterogeneous service offerings including IP telephony commonly referenced by the abbreviation VoIP (or "Voice over IP” for “Voice over IP”) or more generally grouped under the topic of conversational services.
  • VoIP Voice over IP
  • VoIP over IP Voice over IP
  • This overall coverage is achievable through the establishment of interconnection agreements with other third-party service providers to extend the reach of a service outside the administrative boundaries of a single service provider.
  • LS Location Server
  • ITAD telephony domain
  • AS Autonomous System for "Autonomous System”: It is a set of IP resources managed by a single administrative entity, also called “IP connectivity provider”. As part of the BGP inter-domain routing protocol (Border Gateway
  • each AS is identified by a unique identifier.
  • PSTN switched telephone network
  • the telephone operators establish bilateral agreements to extend the overall coverage of the telephone service. The level of coverage achieved depends primarily on the number of agreements reached.
  • Large global operators establish a large number of agreements and can thus join most existing destinations.
  • Local operators establish only a limited number of agreements of which only one or two with large operators. For example, a national incumbent operator in a developing country will establish agreements with other national operators and one or two agreements with global operators to evacuate communications to the rest of the world.
  • IP IP
  • TRlP allows interconnected ITADs to exchange all the destinations they can reach and, in particular, facilitates the selection of the most appropriate "Gateway” or "backbone” to evacuate IP telephony traffic to the RTC network.
  • the TRIP protocol is put implemented by LS ("Location Servers” for “Location Servers”) that propagate TRlP routes containing attributes to qualify the routes in question.
  • LS Local Security Servers
  • This particular protocol is independent of the type of signaling protocol deployed for the actual establishment of calls.
  • TRIP can be used in conjunction with SIP, H.323, or any other signaling protocol.
  • Each LS maintains a local routing database called TRIB ("Telephony Routing Information Database” for "Telephony Routing Information Database”).
  • This basic routing is powered by received listings of neighboring LS (another telephony domain, for example).
  • the operation of the TRIP protocol is similar to that of the Border Gateway Protocol (BGP). Advertisements between neighboring LSs are performed as route update messages, called UPDATE messages. These messages are defined by the TRIP protocol and are exchanged between the LSs to inform the LSs of the same domain or a neighboring domain of the available routes.
  • Border Gateway Protocol Border Gateway Protocol
  • each ITAD being administered by a single telephone operator.
  • IP IP
  • These operators each have one or more LSs.
  • Each LS maintains a routing base that it feeds with advertisements received from its neighbors (ie other domains) and LSs from its own domain. These ads are updated and redistributed to other neighbors if interconnection agreements allow.
  • the 11TAD4 LS 14 updates the advertisements received from the T1TAD5 LS 15 and re-propagates them to ITAD3 13. It should be noted that an ITAD is not necessarily deployed on a single AS or " IP transfer domain ".
  • an LS treats three types of routes: the external routes ("External Routes"), received from LS located in
  • Adj-TRIBs-In 22 stores the routing information conveyed by UPDATE messages. This routing information, also called “routes”, is the input to a route selection process 21 ("Decision Process"). A given LS maintains a table “Adj-TRIB-In” 22 (for adjacent TRIB in which stores the set of route advertisements received from an adjacent LS) by neighbor LS;
  • Ext-TRIB 24 only one "Ext-TRIB” (“external TRIB”) table is maintained by LS.
  • This table contains the result of a route selection process applied to the external roads 25 ("Adj-TRIBs-IN”) and local roads 26 ("Local Routes").
  • the techniques of the prior art allow only one route to be chosen per destination; "Loc-TRIB” 20 (“Local TRIB”): This table contains local routes resulting from the application of local routing policies to each LS; Adj-TRIBs-Out 23: These are the routes that the local LS will announce to their peers.
  • the QoS-Enhanced Border Gateway Protocol (Q-BGP) can be used to determine the QoS processing that will be reserved for voice streams by the QoS. transport layer.
  • Q-BGP QoS-Enhanced Border Gateway Protocol
  • a disadvantage of this technique of the prior art is related to the lack of synchronization between the service layer and the network layer in order to route the media streams. Indeed, in the context of the deployment of the TRIP protocol between neighboring ITADs, the media streams follow either the path determined by the IP routing protocols such as the BGP protocol or the one imposed by the telephony platforms of each ITAD. This last possibility requires, in the context of the use of the SIP protocol for example, to modify several times the content of the SDP part of these messages.
  • a corollary disadvantage of these transfer techniques of the prior art stems from the processing of the media streams by the ASs. Indeed, as these flows follow a path determined by the BGP protocol, NTAD does not have the ability to control the path taken by the stream. Thus, flows may follow an optimum path (for example, better QoS) at the ITAD level, but not at the inter-AS path. This amounts to negating negotiations and agreements between neighboring ITADs if the QoS clauses are not met.
  • a spiral of AS occurs when, after a negotiation between ITAD for the delivery of a media stream, that stream takes several times the same
  • ITTADl 31 1 uses ASl 321 to evacuate its voice traffic
  • TITAD2 312 uses AS2 322.
  • ITT AD3 313 uses ASl 321, that 1TTAD4 314 uses AS4 324.
  • I 1 ITADS 315 uses AS3 323 and ITTAD6 316 uses AS6 326.
  • the best route to reach D 302 from S 301 is via ⁇ AS1, AS4, AS5, AS6 ⁇ .
  • a client S 301 wants to make a call to D 302 and riTAD1111 has chosen the route through ITAD2 312 and 1TAD3 313 to reach ITAD ⁇ 316 to which destination D 302 is attached.
  • This telephone-level route assumes the existence of an IP route (at the level of the transfer layer) traversing the domains: AS1, AS2, AS1, AS6.
  • ASl the level of the transfer layer
  • ASl the domains
  • ITADl is deployed on the two AS, AS1 and AS2, and that ITAD2 is deployed on the AS4 domain and that the two IP telephony operators managing the two ITADs, ITAD1 and ITAD2, have concluded an agreement to interconnect their platforms. services and extend the reach of their voice services to quality of service.
  • ITADl is based on a premium class (ie a class that guarantees an IP transfer with a better quality of service, for example guarantees a loss rate of 99.999% or a maximum delay of less than 50ms) offered by ASl and AS2;
  • ITAD2 uses another premium class offered by AS4.
  • IP network service providers exchange routing information to help build routes in coherent and consistent QoS plans.
  • the premium class of the AS4 is linked to the premium class of 1 ⁇ S2 through a dedicated inter-domain route.
  • two best effort routes ie the routes available thanks to the activation of a routing protocol such as the BGP (Border Gateway Protocol) exist: that which crosses AS1, AS2 and AS4, and the one that crosses ASl, AS3 and AS4, but only one premium route exists.
  • This road crosses ASl, AS2 and AS4 .
  • voice traffic from C 1 to destination of C2 for the telephone service offered by ITADl uses the premium route and not the best effort route, but, unless a static configuration is implemented, the assurance of obtaining an AS1, AS2 traversing route AS4 can not be certain to be obtained by riTADl, so that it is very likely that, at the moment of the actual transfer of the media streams, they pass through AS1, AS3 and AS4.
  • signaling does not have a direct interface to the IP routing protocols that p support the routing of IP packets.
  • the path of the signaling packets may be different from that of the media packets. In this case, the guarantees negotiated during the establishment of the call
  • the solution proposed by the invention makes it possible to overcome these drawbacks of the prior art, by means of a method for selecting a telephony route of at least one digital stream serving a telephony destination, within a first server. of location belonging to a first telephony domain
  • IP deployed on at least one autonomous system said autonomous system exchanging with its neighbors IP routing information designating at least one IP destination to update an IP routing table.
  • said method comprises the following steps: search by the first location server of said IP routing information, said IP routing information comprising an identifier of a second IP telephony domain with which said at least one destination is associated IP telephony, called destination identifier; selecting said IP telephony route to reach said at least one telephony destination, according to a predetermined second telephony domain selection criterion, according to said destination identifier.
  • IP routing information related to the transfer layer This allows the location server that performs the selection to be informed by the autonomic system, IP routes actually used by digital flow during transfer. Autonomous systems therefore communicate with each other IP routes and the locating servers can use this information to perform the selection of the telephony routes.
  • said routing information comprising a list of autonomous system identifiers crossed to reach the telephony destination associated with said identifier of destination
  • the step of searching for said routing information consists in extracting from said routing table of said autonomous system said list of autonomous system identifiers crossed.
  • the invention allows the location server to access a managed routing table at the transfer layer. He can therefore know the roads
  • said method comprises the following steps: receiving at least one route update message from a second location server, said message defining at least one updated telephony route; comprising a list of traversed autonomous system identifiers and a list of IP telephony domains traversed from said telephony destination; extracting from said list of IP telephony domains the identifier of an IP telephony domain with which said telephony destination is associated, said destination identifier; obtaining a set of at least one telephony route, previously stored in said first location server, serving said telephony destination; search, within said at least one autonomous system, of at least one IP route whose said at least one IP destination is identical to said destination identifier, said IP routes searched; selecting a telephony route, within said set of telephony roads, including a list of autonomous systems traversed includes the same identifiers of autonomous systems that the list of autonomous systems identifiers of said at least one searched route, when such a road
  • the location server performing the selection of the route therefore implements a method that makes it possible to choose a route taking into account the routing information.
  • This method is based on the reception, by the location server, of update messages. These messages include a list of autonomous system identifiers inserted into the telephony route.
  • the telephony route includes information identifying the route
  • the location server retrieves the identifier of the telephony domain of the destination and obtains a telephony route list that serves that destination. This obtaining enables him to search, within his own autonomous system, at least one IP route (at the transfer level) which serves this destination.
  • the system can therefore select a route according to two channels or selection criteria: if it identifies, within the set of telephony routes, a route whose list of autonomous systems crossed includes the same autonomous system identifiers as the list autonomous system identifiers of the searched route, then it selects this identified route; if not, it selects a route that serves the same destination according to another criterion. It can, for example, be the first telephony route found.
  • the server then stores this selected route. It will then be used for the routing of digital flows during a routing process.
  • such a method comprises a step of transmitting at least one route update message to a location server, said message defining at least one updated telephony route comprising at least one identifier of at least one autonomous system and at least one identifier of at least one IP telephony domain.
  • the location server keeps its peers informed of the selection it has made. The other location servers are therefore able to use and take into account this route.
  • such a method comprises the following steps: receiving at least one route update message from a second location server located in said first telephony domain, said message defining at least one updated telephony route comprising a list of traversed autonomous system identifiers and a list of IP telephony domains traversed from said destination; storing said at least one updated telephony route.
  • the location server therefore has the ability to receive updated telephony routes by its peers located in the same telephony domain as itself. It can therefore realize an immediate storage of this road.
  • said list of autonomous system identifiers is ordered according to at least one predetermined scheduling criterion and said selection step takes account of said at least one predetermined scheduling criterion.
  • the list of identifiers allows the location server to identify the autonomous systems used by the telephony route. This list, for a given route, can be ordered, namely to indicate, for example, the order in which the autonomous systems are traversed by the digital stream.
  • the location server is aware of the standard of scheduling and the order given to autonomous road systems.
  • the selection of the telephony route by the autonomous system can take into account this scheduling, in order, for example, to optimize the telephony path.
  • the list of independent identifiers servers is not orderly and said selection step takes into account the first identifier of said autonomous system identifier list.
  • the process selection step implemented by the location server is only the first identifier of the list. So even if a location server transmits a road that is not ordered, the location server that processes this information is able to realize a route selection based on the road that has been provided by the message update.
  • the invention also relates to a device for selecting a telephony route of at least one digital stream serving a telephony destination within a first location server belonging to a first IP telephony domain deployed on at least one system.
  • autonomous transfer system said autonomous system exchanging with its neighbors IP routing information designating at least one IP destination to update an IP routing table
  • said device comprises the means of: searching said IP routing information, said IP routing information comprising an identifier of a second IP telephony domain which is associated with said at least one destination IP telephony, said identifier destination; selecting said IP telephony route to reach said at least one telephony destination, according to a predetermined second telephony domain selection criterion, according to said destination identifier.
  • such a device comprises means for implementing the steps of the method of selecting telephony routes, as described above.
  • the invention also relates to a computer program product downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • such a computer program product includes program code instructions for the execution of the telephony route selection process as described above.
  • the invention also relates to a propagation signal for implementing the routing route propagation method.
  • a propagation signal for implementing the routing route propagation method.
  • such a signal comprises a route update message including data representative of a list of identifiers of crossed autonomous systems and a list of IP telephony domains traversed from said destination.
  • FIG. 1 shows an example of telephony domain architecture (ITAD);
  • FIG. 2 illustrates the structure of the routing databases (TRIB) used by the location servers (LS) routing the calls in the telephony domains (ITAD) presented in FIG. 1;
  • FIG. 3 describes the spiral phenomenon of the AS occurring during the choice of a telephony route according to the techniques of the prior art;
  • FIG. 4 illustrates the need to obtain synchronization between the transport layer and the service layer;
  • FIG. 5 depicts the new routing database structure for an LS according to the invention
  • FIG. 6 illustrates an example of synchronization realized using the method according to the invention.
  • the invention therefore proposes to perform a synchronization between the transfer layer and the service layer in order to avoid the AS spiral phenomena and the quality of service depreciation.
  • the general principle of the invention rests on the taking into account by a
  • Adj-TRIBs-In 22 stores the routing information conveyed by UPDATE messages. These routing info ⁇ nations, also called “routes", are the inputs of a route selection process 21 ("Decision Process").
  • a given LS maintains a table “Adj-TRIB-In” 22 (for adjacent TRIB in which stores the set of route advertisements received from an adjacent LS) by neighbor LS;
  • Ext-TRIB 24 only one "Ext-TRIB” table (“TRIB externat”) is maintained by LS.
  • This table contains the result of a route selection process applied to the external roads ("Adj-TRIBs-fN") and local roads 26 ("Local Routes").
  • the techniques of the prior art only allow to choose one route per destination; "Loc-TRIB” 20 (“Local TRIB”):
  • This table contains local routes resulting from the application of local routing policies to each LS;
  • Adj-TRIBs-Out” 23 (“Adjacent TRlB out”): These are the routes that the local LS will announce to their peers.
  • This cache is provided by the IP connectivity provider (Administrative Entity managing an AS) either as a set of permissions to access the routing tables or by l intermediate of an "looking glass” (process for visualizing IP routes on IP backbones).
  • This table can be, for example, the copy of the routing tables (RIB,
  • This new table is used, for example, by a TRIP route selection process to ensure synchronization between the transport layer and the service layer.
  • Each ITAD has an identifier in the form of an AS number or a routable IP address; - This identifier is the same as that used by the TRIP protocol to provide the attributes "AdvertisementPath" and "RoutedPath";
  • ITAD identifiers are announced in an interdomain routing protocol such as BGP or q-BGP. These identifiers may not be the true IP addresses of the LSs; -
  • Each IP connectivity service provider (administrative entity managing the AS) provides IP telephony operators (managing an ITAD) an interface or a cache of its local routing table (Cache_Local_RlB) filled in by an inter-domain routing protocol such as BGP or q-BGP. This cache is updated at the request of IP telephony service providers or dynamically through another mechanism;
  • the local LS queries the local RIB cache (ie Cache_Local_RIB) between domains to find the path to join
  • the LS retrieves the BGP attribute
  • AS_PATH (BGP specific attribute) This attribute informs the list of IP domains traversed by the BGP route in question.
  • the local LS searches in its "Adj_TRIB_In” the existence of other routes towards DEST, whose list of AS used to carry voice traffic with identical characteristics to
  • the LS extracts the identifier of the first AS from the list, that is to say the identifier of the next AS, denoted ASid.
  • the LS searches, among the routes to DEST, contained in the Adj_TRIB_ln, the one whose next provider of IP connectivity is identical to ASid. This route is then stored in the "Local_TRIB" table. If no route exists then the LS executes a standard selection process or other local policies; 5.3 Example of implementation To illustrate the synchronization procedure, consider the example illustrated in Figure 6. Suppose that ITADl 61 1 uses ASl 621 to evacuate its voice traffic, that ITAD2 612 uses AS2 622, that ITAD3 613 uses ASl
  • ITAD4 614 uses AS2 622
  • ITAD5 615 uses AS3 623
  • ITAD ⁇ 616 uses AS6 626. It is assumed that to join D 602 from S 601, the AS path chosen by Inter-domain routing protocol is ASl, AS2, AS3, AS6 (621,
  • ITAD6 announces its prefixes to ITAD5 and ITAD3; - ITAD3 and ITAD5 have no routes other than those received from ITAD6 to serve ITAD ⁇ prefixes including D. Therefore, ITAD3 and ITAD5 store these routes in their local TRlBs and announce (through UPDATE messages). These prefixes to ITAD4 for rITAD5 and ITAD2 for TITAD3; - The same procedure applies for ITAD4 and ITAD2 from FITAD3 and riTAD5.
  • ITADl receives two routes to serve the same prefixes, it consults the cache of local routing tables provided by I " ASl to find the route selected by the inter-domain routing protocol to the ITADô identifier .This query returns the path ⁇ AS2, AS3, AS6 ⁇ . ITADl chooses the TRlP route received from ITAD4 and stores it in its table
  • this information can improve the quality of service.
  • an LS has a simple and effective way to optimize an end-to-end path for a given destination.
  • This same information also makes it possible to detect anomalies, such as IP spirals for example, since the service layer is aware of the ASs through which the data travels.
  • the present application describes only the principle of information feedback, or identifiers for the IP layer.
  • a list of identifiers relating to the IP layer is obtained, and then propagated between the LSs implemented by the ITADs.
  • an AS number identifies the IP connectivity provider at the transport layer to carry voice. This number is provided to an administrative management domain (ITAD) which forwards it to a neighboring domain.
  • ITID administrative management domain
  • This document presents an embodiment based on the location servers LS. It is understood that this embodiment is that an example of implementation. Especially. the invention can quite be implemented using proximity servers (also called “proxy” servers).
  • TRlP protocol is implemented by the LS (location servers) that propagate TRIP routes, containing attributes to qualify the routes exchanged.
  • the standard version of the TRIP protocol (detailed in Rosenberg et al .: RFC3219: “Telephony Routing over IP (TRlP)" of January 2002) provides for alternate routing information between two neighboring LSs via the UPDATE message. which has a number of attributes.
  • This attribute includes the following attributes:
  • This attribute indicates whether the attribute in question should be filled in or not in a TRIP message.
  • TRIP Type Code The unique identifier of the TRlP message in question. The purpose of this attribute is to create and store a list of traversed ASs to reach the destination in question. In other words, it is an attribute of the service layer which contains information relating to the transport layer. It is then propagated from an IP telephony domain (ITAD) to a neighboring IP telephony domain.
  • ITID IP telephony domain
  • the AS_PATH attribute is composed of a sequence of segments, or fields, "AS path".
  • Each segment "AS path” is composed of a triplet ⁇ path segment type, path segment length. path segment value>, defined as follows: each "path segment type” has a length of 1 byte which can take the following values:
  • each path segment length has a length of 1 byte and contains the number of AS contained in the path segment value; the field "path segment value" contains one or more AS numbers. each encoded as a field of 2 bytes long. This new attribute therefore lists the succession of AS traversed by the data associated with a call.
  • Each LS maintains a routing table that it feeds with the announcements received from the neighbors and LSs of its own domain. These ads are updated and redistributed to other neighbors if the agreements allow.
  • an LS when an LS propagates a TRIP route that it has learned in an UPDATE message from another neighboring LS, it is expected that it modifies the new AS_PATH attribute of the route according to the type of LS to which it is to re - propagate the route, according to the following procedure.
  • LS peer If the LS to which the route is advertised (LS peer) is not located in the same ITAD, two cases arise for the update of the attribute AS_PATH: if the first segment of the AS_PATH is of type AS_SEQUENCR, the local system adds the number of its IP connectivity service provider as the last element of the sequence; if the first segment of the AS_PATH is of type AS_SET, the local system adds a new segment of type AS_SEQUENCE at the beginning of the AS_PATH; this new segment contains the domain number of its IP connectivity service provider.
  • the advertisement includes the IP connectivity service provider's number in the AS PATH attribute of all UPDATE messages to be sent to its TRIP peers in neighboring ITADs.
  • the LS includes an empty AS P ATH in all UPDATE messages to send to its TRIP peers in its own ITAD.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de sélection d'une route de téléphonie d'au moins un flux numérique desservant une destination de téléphonie, au sein d'un premier serveur de localisation appartenant à un premier domaine de téléphonie IP déployé sur au moins un système autonome, ledit système autonome échangeant avec ses voisins des informations de routage IP désignant au moins une destination IP pour mettre à jour une table de routage IP. Selon l'invention, ledit procédé comprend les étapes suivantes de : recherche par le premier serveur de localisation desdites informations de routage IP, lesdites informations de routage IP comprenant un identifiant d'un deuxième domaine de téléphonie IP auquel est associée ladite au moins une destination de téléphonie IP, dit identifiant de destination; sélection de ladite route de téléphonie IP pour atteindre ladite au moins une destination de téléphonie, selon un critère prédéterminé de sélection de deuxième domaine de téléphonie, en fonction dudit identifiant de destination.

Description

Procédé de sélection d'une route de téléphonie au sein d'un domaine de téléphonie IP, dispositif et programme d'ordinateur correspondants.
1 DOMAINE DE L'INVENTION
La présente invention se rapporte au domaine de la téléphonie sur des réseaux de type Internet. Par téléphonie, on entend tout aussi bien les services de téléphonie classiques ou intégrant des services évolués tels que la visiophonie ou le service de transfert de données numériques synchrones.
La présente invention se rapporte plus particulièrement à l'échange d'information pour permettre la synchronisation entre la couche service (c'est à dire celle s'occupant du routage d'appel) et la couche réseau (c'est à dire celle s'occupant du transfert de datagrammes IP) pour router des flux d'information entre des domaines de téléphonie IP.
Le réseau IP est le réseau fédérateur adopté par les opérateurs pour mutualiser leurs offres de service hétérogènes dont la téléphonie IP couramment référencée par le sigle VoIP (de l'anglais « Voice over IP » pour « Voix sur IP ») ou plus généralement groupée sous le thème des services conversationnels.
Le déploiement de ces applications de voix ou de vidéo en temps réel vers le tout IP ainsi que la migration du réseau commuté, traditionnellement désigné par le RTC, contraint les opérateurs à fournir une couverture globale, à l'échelle mondiale, de ces services. Ceci ne se résume pas seulement à assurer des points de présence aux quatre coins du globe mais à offrir aux clients la possibilité de joindre n'importe quelle destination (à savoir les clients des autres opérateurs).
Cette couverture globale est réalisable grâce à l'établissement d'accords d'interconnexion avec d'autres fournisseurs de service tiers afin de pouvoir étendre la portée d'un service en dehors des bordures administratives d'un seul fournisseur de service.
Dans le fil de cette dynamique, on prévoit que la coopération entre les fournisseurs de service de VoIP/ToIP (« Telephony over IP » pour « Téléphonie sur IP ») s'intensifiera dans le court et le moyen terme. Cette intensification doit permettre l'évacuation du trafic lié à la \oix vers des points de terminaison se trouvant en dehors des domaines de téléphonie IP (encore appelés « ITAD » de l'anglais « IP Telephony Administrative Domain ») des opérateurs. Ces coopérations entre fournisseurs sont d'autant plus stratégiques que les accords classiques de type bilatéraux ne permettent pas d'assurer la couverture globale requise par les opérateurs.
De plus, les offres de téléphonie déployées au dessus d'un réseau IP doivent répondre à des contraintes de qualité telles que la haute disponibilité et la forte tolérance aux pannes. La contrainte de disponibilité du service ne concerne pas uniquement la couche service mais également la couche transport. Dans la suite de ce document on emploiera indifféremment les termes de
« Qualité de Service » ou de « QoS » qui désignent la même notion. On fait également référence aux termes suivants :
LS (« Location Server » pour « Serveur de Localisation ») : c'est une entité d'un domaine de téléphonie (ITAD) qui gère les localisations des clients et des routes d'un ITAD local. Cet équipement peut s'interfacer avec un LS voisin pour apprendre la localisation des clients gérés par d'autres ITAD ;
AS (« Autonomous System » pour « Système Autonome ») : C'est un ensemble de ressources IP gérées par une seule entité administrative, également appelée « fournisseur de connectivité IP ». Dans le cadre du protocole de routage inter domaines BGP (de l'anglais « Border Gateway
Protocol », [RFC 1771]), chaque AS est identifié par un identifiant unique.
Cet AS est également appelé « Domaine de Transfert IP ».. q-BGP : une version évoluée du protocole BGP permettant d'échanger des routes valorisant des paramètres de QoS. 2 SOLUTIONS DE L'ART ANTERIEUR
2.1 Art antérieur
En téléphonie « classique » (monde RTC, réseau téléphonique commuté). les opérateurs de téléphonie établissent des accords bilatéraux pour étendre la couverture globale du service téléphonique. Le niveau de couverture atteint dépend essentiellement du nombre d'accords établis. On peut très schématîquement considérer que deux catégories d'opérateurs de télécommunications existent : les opérateurs locaux et/ou nationaux et les opérateurs mondiaux. Les grands opérateurs mondiaux établissent un grand nombre d'accords et peuvent ainsi joindre la plupart des destinations existantes. Les opérateurs locaux établissent seulement un nombre limité d'accords dont seulement un ou deux avec de grands opérateurs. Ainsi, un opérateur national historique d'un pa>s en voie de développement va établir des accords avec d'autres opérateurs nationaux et un ou deux accords avec des opérateurs mondiaux pour évacuer les communications vers le reste du monde. Actuellement, la plupart des opérateurs migrent leurs réseaux RTC vers des solutions et des infrastructures basées sur le protocole « IP ». Pour accompagner le déploiement de services de « VoIP », l'IETF (« Internet Engineering Task Force » pour « Groupe de développement de l' internet ») a porté de nombreux travaux de standardisation. Plusieurs protocoles ont été spécifiés parmi lesquels on peut citer SIP (« Session Initiation Protocol » pour « Protocole d'initialisation de session »), SDP (« Session Description Protocol » pour « protocole de description de session »), RTP (« Real-time Transfer Protocol » pour « Protocole de transfert en temps réel »), RTCP (« Real-time Transfer Control Protocol » pour « Protocole de contrôle de transfert en temps réel »), MGCP (« Multimedia Gateway Control Protocol » pour « Protocole de contrôle d'épine dorsale multimédia »), SAP (« Session Announcement Protocol » pour « Protocole d'annonce de session ») et TRlP (Telephony Routing Over IP, [RFC3219J pour « Routage de la téléphonie IP »). Ces protocoles répondent à des besoins différents et intègrent en particulier la signalisation et la commande des appels, l'échange des flux média et leur contrôle et l'échange d'informations de routage des appels.
TRlP permet à des ITAD interconnectés d'échanger l'ensemble des destinations qu'ils peuvent joindre et facilite en particulier Ia sélection des « Gateway » (« Autoroute » ou « épine dorsale ») les plus appropriées pour évacuer du trafic de téléphonie IP vers le réseau RTC. Le protocole TRIP est mis en œuvre par des LS (« Location Servers » pour « Serveurs de localisation ») qui propagent des routes TRlP contenant des attributs permettant de qualifier les routes en question. L'utilisation de ce protocole particulier est indépendante du type du protocole de signalisation déployé pour l'établissement effectif des appels. Le protocole TRIP peut être utilisé conjointement avec SIP, H.323 ou tout autre protocole de signalisation. Chaque LS maintient une base de données de routage locale dite TRIB (« Telephony Routing Information Database » pour « Base de données d'information de routage de téléphonie »). Cette base de routage est alimentée par des annonces reçues des LS voisins (d'un autre domaine de téléphonie, par exemple). Le fonctionnement du protocole TRIP est similaire à celui du protocole BGP (« Border Gateway Protocol »). Les annonces entre LS voisins sont effectuées sous la forme de messages de mise à jour de route, nommés messages «UPDATE ». Ces messages sont définis par le protocole TRIP et sont échangés entre les LS pour informer les LS du même domaine ou d'un domaine voisin des routes disponibles.
On décrit, en relation avec Ia figure 1 , l'activation du protocole TRlP entre différents ITAD (pour des raisons de simplicité, on utilise également le terme « domaine » pour dénoter un ITAD), chaque ITAD étant administré par un seul opérateur de téléphonie IP. Ces opérateurs disposent chacun d'un ou plusieurs LS. Chaque LS maintient une base de routage qu'il alimente avec des annonces reçues de ses voisins (c'est à dire d'autres domaines) et des LS de son propre domaine. Ces annonces sont mises à jour et redistribuées à d'autres voisins si les accords d'interconnexion le permettent.
Ainsi le LS de 11TAD4 14, par exemple, met à jour les annonces reçues du LS de T1TAD5 15 et les re-propage à ITAD3 13. Il convient de noter qu'un ITAD n'est pas nécessairement déployé sur un seul AS ou « domaine de Transfert IP ».
Du point de vue routage, un LS traite trois types de routes: les routes externes (« External Routes »), reçues de LS situés dans des
ITAD voisins ; - les routes internes (Internai Routes), reçues de LS situés dans le même ITAD ; les routes locales (Local Routes), configurées localement dans chaque LS pour être injectées dans les processus TRlP. Cette opération est réalisée soit par configuration statique ou par redistribution d'informations provenant d'autres protocoles de routage.
Ces routes sont gérées dans des tables de routage nommées « TRlB »
(« Telephony Routing Information Base » pour « Base d'information de routage de la téléphonie »). Ainsi, quatre types de « TRIB » sont gérés par un LS comme l'illustre la figure 2. Ces tables existent pour un même LS, les relations entre ces tables sont illustrées en relation avec la figure 2.
« Adj-TRIBs-In » 22 : stocke les informations de routage véhiculées par des messages UPDATE. Ces informations de routage, également appelées « routes », sont les entrées d'un processus de sélection 21 de routes (« Décision Process »). Un LS donné maintient une table « Adj-TRIB-In » 22 (pour adjacent TRIB in qui stocke l'ensemble d'annonces de routes reçues de la part d'un LS adjacent) par LS voisin ;
« Ext-TRIB » 24: une seule table « Ext-TRIB » (« external TRIB ») est maintenue par LS. Cette table contient le résultat d'un processus de sélection de routes appliqué aux routes externes 25 (« Adj-TRIBs-IN ») et locales 26 (« Local Routes »). Les techniques de l'art antérieur ne permettent de choisir qu'une seule route par destination ; « Loc-TRIB » 20 (« Local TRIB »): cette table contient les routes locales résultant de l'application des politiques de routage locales à chaque LS ; « Adj-TRIBs-Out » 23 (« Adjacent TRIB out »): Ce sont les routes que le LS local annoncera à ses pairs.
Dans la couche transport, on peut utiliser le protocole q-BGP (« QoS- Enhanced Border Gateway Protocol » pour « Protocole de Routage Interdomaine à Qualité de Service Augmentée ») afin de connaître le traitement de QoS qui sera réservé aux flux voix par la couche transport. 2.2 Inconvénients de l'art antérieur
Un inconvénient de cette technique de l'art antérieur est lié à l'absence de synchronisation entre la couche service et la couche réseau afin de router les flux média. En effet, dans le cadre du déploiement du protocole TRIP entre des ITAD voisins, les flux média suivent soit le chemin déterminé par les protocoles de routage IP tel que le protocole BGP ou celui imposé par les plateformes de téléphonie de chaque ITAD. Cette dernière possibilité nécessite, dans le cadre de l'utilisation du protocole SIP par exemple, de modifier plusieurs fois le contenu de la partie SDP de ces messages. Un inconvénient corollaire de ces techniques de transfert de l'art antérieur découle du traitement des flux média par les AS. En effet, comme ces flux suivent un chemin déterminé par le protocole BGP, NTAD n'a pas la possibilité de contrôler le chemin emprunté par le flux. Ainsi, il se peut que les flux suivent un chemin optimum (par exemple par meilleure QoS) au niveau des ITAD, mais pas au niveau du chemin inter AS. Ce qui revient à réduire à néant les négociations et les accords passés entre ITAD voisins si les clauses de QoS ne sont pas satisfaites.
Dans le cas d'une configuration statique du chemin d'AS à emprunter par les flux média, cette possibilité nécessite, dans le cadre de l'utilisation du protocole SIP par exemple et lors du transfert effectif des flux, de modifier plusieurs fois le contenu de la partie SDP des messages SIP. Ce traitement peut induire des délais supplémentaires dans le cas où plusieurs AS doivent être traversés et peut nuire à la Qualité de Service perçue par le client final.
Un autre inconvénient de cette technique de l'art antérieur est lié au phénomène de spirale d'AS. On présente ce phénomène de spirale des AS en relation avec la figure 3.
Une spirale d'AS se produit quand, à l'issue d'une négociation entre ITAD pour l'acheminement d'un flux média, ce flux emprunte plusieurs fois un même
AS avant d'arriver à destination. Supposons que ITTADl 31 1 utilise ASl 321 pour évacuer son trafic voix, que TITAD2 312 utilise AS2 322. que ITT AD3 313 utilise ASl 321 , que 1TTAD4 314 utilise AS4 324. que I1ITADS 315 utilise AS3 323 et que ITTAD6 316 utilise AS6 326. Supposons également que la meilleure route pour atteindre D 302 depuis S 301 est de passer par {AS1, AS4, AS5, AS6}.
Supposons qu'un client S 301 veuille passer un appel vers D 302 et que riTADl 311 ait choisi la route passant par ITAD2 312 et 1TAD3 313 pour atteindre l'ITADό 316 auquel la destination D 302 est attachée. Cette route de niveau téléphonique suppose l'existence d'une route IP (au niveau de la couche de transfert) traversant les domaines : ASl, AS2, ASl, AS6. On remarque donc que l'on passe plusieurs fois par le même AS, en l'occurrence ASl . Ceci constitue une spirale au niveau IP et peut nuire aux performances de transfert IP car on passe par l'ASl plusieurs fois. Ce phénomène peut toutefois être évité si les flux média suivent le chemin BOP et non celui imposé par les plateformes de service.
Afin d'illustrer une nouvelle fois ce phénomène, on suppose maintenant que le chemin choisi par ITADl pour joindre D est (ITADl , ITAD4, ITAD5, ITAD6}. Ceci signifie que le chemin d'AS suivi sera {AS1, AS4, AS3, AS6}. Or il n'existe pas de lien direct entre AS4 et AS3. Ainsi ce chemin d'AS devient soit (ASl , AS4, AS5, AS6, AS3, AS6} soit (ASl , AS4, ASl, AS2, AS3, AS6}. Dans les deux cas, ces chemins ne sont pas optimaux au niveau transfert IP et sont différents de celui choisi par BGP.
Un autre inconvénient de cette technique de l'art antérieur est lié à l'absence de synchronisation entre la couche service et le plan de transfert. On décrit ce phénomène en relation avec la figure 4, dans le cas de la téléphonie IP.
On suppose ici que ITADl est déployé sur les deux AS, ASl et AS2, et que ITAD2 est déployé sur le domaine AS4 et que les deux opérateurs de téléphonie IP gérant les deux ITAD, ITADl et ITAD2, ont conclu un accord pour interconnecter leurs plateformes de services et étendre ainsi la portée de leurs services de voix à qualité de service.
Pour évacuer son trafic voix, ITADl repose sur une classe premium (c'est à dire une classe qui garantit un transfert IP avec une meilleure qualité de service, par exemple garantit un taux de perte à 99,999% ou un délai maximum inférieur à 50ms) offerte par ASl et AS2; De même, ITAD2 utilise une autre classe premium offerte par AS4. Au niveau IP. les fournisseurs de service de réseau IP échangent des informations de routage pour permettre de construire des routes dans des plans de QoS cohérents et consistants. Ainsi, la classe premium de l'AS4 est liée à la classe premium de 1ΑS2 par le biais d'une route inter domaines dédiée. Ainsi, pour joindre C2 à partir de Cl, deux routes best effort (c'est à dire les routes disponibles grâce à l'activation d'un protocole de routage tel que le BGP (Border Gateway Protocol) existent: celle qui traverse ASl , AS2 et AS4. et celle qui traverse ASl, AS3 et AS4. Par contre une seule route premium existe. Cette route traverse ASl, AS2 et AS4. Pour assurer la cohérence du service, il faut que le trafic de voix issue de C 1 à destination de C2 au titre du service de téléphonie offert par ITADl utilise la route premium et non la route best effort. Or, à moins de mettre en œuvre une configuration statique, l'assurance de l'obtention d'une route traversant ASl, AS2 et AS4 ne peut être obtenue de façon certaine par riTADl . Ainsi, il se peut très bien qu'au moment du transfert effectif des flux média, ceux-ci transitent par ASl, AS3 et AS4. Ceci est dû au fait que le protocole de signalisation ne dispose pas d'interface directe avec les protocoles de routage IP qui prennent en charge l'acheminement des paquets IP. Ainsi le chemin des paquets de signalisation peut être différent de celui des paquets média. Dans ce cas de figure, les garanties négociées au cours de l'établissement de l'appel sont obsolètes.
De plus, ces techniques de configuration centralisées et bilatérales présentent l'inconvénient de ne plus être en adéquation avec les besoins de couverture, puisque le nombre d'accords à établir pour offrir une couverture globale devient important. Qui plus est. les accords bilatéraux au niveau service ne suffisent pas pour offrir un service de qualité. Ceci est dû au fait que la qualité de service perçue par l'utilisateur intègre aussi celle rendue par la couche transfert. Pour faire vivre ce mode, les operateurs réseau doivent alors établir des accords de connectivité IP de la même nature, présentant le même niveau de qualité de service. Or, compte tenu du nombre important d'AS (plus de 17000), de tels accords ne peuvent pas être mis en place.
3 RESUME DE L'INVENTION
La solution proposée par l'invention permet de pallier ces inconvénients de l'art antérieur, grâce à un procédé de sélection d'une route de téléphonie d'au moins un flux numérique desservant une destination de téléphonie, au sein d'un premier serveur de localisation appartenant à un premier domaine de téléphonie
IP déployé sur au moins un système autonome, ledit système autonome échangeant avec ses voisins des informations de routage IP désignant au moins une destination IP pour mettre à jour une table de routage IP.
Selon l'invention, ledit procédé comprend les étapes suivantes de : recherche par le premier serveur de localisation desdites informations de routage IP, lesdites informations de routage IP comprenant un identifiant d'un deuxième domaine de téléphonie IP auquel est associée ladite au moins une destination de téléphonie IP, dit identifiant de destination; sélection de ladite route de téléphonie IP pour atteindre ladite au moins une destination de téléphonie, selon un critère prédéterminé de sélection de deuxième domaine de téléphonie, en fonction dudit identifiant de destination.
Ainsi, il est possible de tenir compte, lors de la sélection des routes de téléphonie, des informations de routage IP, liées à la couche transfert. Ceci permet au serveur de localisation qui réalise la sélection d'être informé par le système autonome, des routes IP empruntées effectivement par les flux numériques lors de leur transfert. Les systèmes autonomes communiquent donc entre eux les routes IP et les serveurs de locaiisation peuvent utiliser ces informations pour effectuer Ia sélection des routes de téléphonie.
Selon une caractéristique originale de l'invention, lesdites informations de routage comprenant une liste d'identifiants de systèmes autonomes traversés permettant d'atteindre la destination de téléphonie associée audit identifiant de destination, l'étape de recherche desdites informations de routage consiste à extraire de ladite table de routage dudit système autonome ladite liste d'identifiants de systèmes autonomes traversés.
Ainsi, l'invention permet au serveur de localisation d'accéder à une table de routage gérée au niveau de la couche transfert. Il peut donc connaître les routes
IP choisies pour véhiculer les flux média jusqu'à une destination de téléphonie et récupérer la liste des systèmes autonomes traversés.
Selon une caractéristique originale de l'invention, ledit procédé comporte les étapes suivantes : - réception d'au moins un message de mise à jour de route en provenance d'un deuxième serveur de localisation, ledit message définissant au moins une route de téléphonie actualisée comprenant une liste d'identifiants de systèmes autonomes traversés et une liste de domaines de téléphonie IP traversés depuis ladite destination de téléphonie ; - extraction, dans ladite liste de domaines de téléphonie IP, de l'identifiant d'un domaine de téléphonie IP auquel est associée ladite destination de téléphonie, dit identifiant de destination ; obtention d'un ensemble d'au moins une route de téléphonie, préalablement stockée au sein dudit premier serveur de localisation, desservant ladite destination de téléphonie ; recherche, au sein dudit au moins un système autonome, d'au moins une route IP dont ladite au moins une destination IP est identique audit identifiant de destination, dites routes IP recherchées ; sélection d'une route de téléphonie, au sein dudit ensemble de routes de téléphonie, dont une liste de systèmes autonomes traversés comprend les mêmes identifiants de systèmes autonomes que ladite liste d'identifiants de systèmes autonomes de ladite au moins une route recherchée, lorsqu'une telle route existe ; sélection d'une route de téléphonie dudit ensemble de routes d'acheminement de téléphonie, lorsqu'il n'existe pas de route dont une liste de systèmes autonomes traversés comprend les mêmes identifiants de systèmes autonomes que ladite liste d'identifiants de systèmes autonomes, selon au moins un critère prédéterminé ; stockage de ladite route de téléphonie sélectionnée. Le serveur de localisation effectuant la sélection de la route met donc en œuvre un procédé qui permet de choisir une route tenant compte des informations de routage. Ce procédé se base sur la réception, par le serveur de localisation, de messages de mise à jour de route. Ces messages comprennent une liste d'identifiants de système autonomes insérée dans la route de téléphonie. Ainsi la route de téléphonie comprend une information identifiant la route
IP empruntée. Le serveur de localisation récupère l'identifiant du domaine de téléphonie de la destination et obtient une liste de route de téléphonie qui dessert cette destination. Cette obtention lui permet de rechercher, au sein de son propre système autonome, au moins une route IP (au niveau transfert) qui dessert cette destination. Le système peut donc sélectionner une route suivant deux voies ou critères de sélection : s'il identifie, au sein de l'ensemble de routes de téléphonie, une route dont la liste de systèmes autonomes traversés comprend les mêmes identifiants de systèmes autonomes que la liste d'identifiants de systèmes autonomes de la route recherchée, alors il sélectionne cette route identifiée ; dans le cas contraire, il sélectionne une route qui dessert la même destination selon un autre critère. Il peut, par exemple, s'agir de la première route de téléphonie trouvée.
Le serveur stocke ensuite cette route sélectionnée. Elle servira par la suite à l'acheminement des flux numériques lors d'un processus d'acheminement.
Selon un aspect particulier de l'invention, un tel procédé comporte une étape d'émission d'au moins un message de mise à jour de route vers un serveur de localisation, ledit message définissant au moins une route de téléphonie actualisée comprenant au moins un identifiant d'au moins un système autonome et au moins un identifiant d'au moins un domaine de téléphonie IP. Ainsi, le serveur de localisation tient ses pairs informés de la sélection qu'il a effectuée. Les autres serveurs de localisation sont donc à même d'utiliser et de prendre en compte cette route.
Selon une caractéristique particulière de l'invention, un tel procédé comporte les étapes suivantes : réception d'au moins un message de mise à jour de route en provenance d'un deuxième serveur de localisation situé dans ledit premier domaine de téléphonie, ledit message définissant au moins une route de téléphonie actualisée comprenant une liste d'identifiants de systèmes autonomes traversés et une liste de domaines de téléphonie IP traversés depuis ladite destination ; stockage de ladite au moins une route de téléphonie actualisée.
Le serveur de localisation dispose donc de la capacité de recevoir des routes de téléphonie actualisées par ses pairs situés dans le même domaine de téléphonie que lui. Il peut donc réaliser un stockage immédiat de cette route.
Selon un aspect particulier de l'invention, ladite liste d'identifiants de systèmes autonomes est ordonnée selon au moins un critère d'ordonnancement prédéterminé et ladite étape de sélection tient compte dudit au moins un critère d'ordonnancement prédéterminé. La liste des identifiants permet au serveur de localisation d'identifier les systèmes autonomes empruntés par la route de téléphonie. Cette liste, pour une routé donnée, peut être ordonnée, à savoir indiquer par exemple, Tordre dans lequel les systèmes autonomes sont traversés par le flux numérique. Ainsi le serveur de localisation a connaissance du critère d'ordonnancement et de Tordre donné aux systèmes autonomes de la route. La sélection de la route de téléphonie par le système autonome peut tenir compte de cet ordonnancement, afin, par exemple, d'optimiser le chemin de téléphonie.
Selon une caractéristique originale de l'invention, ladite liste d'identifiants de serveurs autonomes n'est pas ordonnée et ladite étape de sélection tient compte du premier identifiant de ladite liste d'identifiants de systèmes autonome. Lorsque la liste n'est pas ordonnée, l'étape de sélection du procédé mis en œuvre par le serveur de localisation ne tient que du premier identifiant de la liste. Ainsi, même si un serveur de localisation transmet une route qui n'est pas ordonnée, le serveur de localisation qui traite cette information est à même de réaliser un choix de route en se basant sur la route qui lui a été fourni par le message de mise à jour.
L'invention concerne également un dispositif de sélection d'une route de téléphonie d'au moins un flux numérique desservant une destination de téléphonie au sein d'un premier serveur de localisation appartenant à un premier domaine de téléphonie IP déployé sur au moins un système de transfert autonome, ledit système autonome échangeant avec ses voisins des informations de routage IP désignant au moins une destination IP pour mettre à jour une table de routage IP,
Selon l'invention, ledit dispositif comprend les moyens de : recherche desdites informations de routage IP, lesdites informations de routage IP comprenant un identifiant d'un deuxième domaine de téléphonie IP auquel est associée ladite au moins une destination de téléphonie IP, dit identifiant de destination; sélection de ladite route de téléphonie IP pour atteindre ladite au moins une destination de téléphonie, selon un critère prédéterminé de sélection de deuxième domaine de téléphonie, en fonction dudit identifiant de destination.
Plus généralement, un tel dispositif comprend des moyens de mise en œuvre des étapes du procédé de sélection de routes de téléphonie, tel que décrit précédemment. Dans un autre mode de réalisation, l'invention concerne également un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur.
Selon l'invention, dans au moins un mode de réalisation, un tel produit programme d'ordinateur comprend des instructions de code de programme pour l'exécution du procédé de sélection de routes de téléphonie tel que décrit précédemment.
L'invention concerne également un signal de propagation pour la mise en œuvre du procédé de propagation de routes d'acheminements. Selon l'invention, un tel signal comprend un message de mise à jour de route comprenant des données représentatives d'une liste d'identifiants de systèmes autonomes traversés et une liste de domaines de téléphonie IP traversés depuis ladite destination.
4 LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1, déjà commentée, présente un exemple d'architecture de domaines de téléphonie (ITAD) ; la figure 2 illustre la structure des bases de données de routage (TRIB) utilisées par les serveurs de localisation (LS) routant les appels dans les domaines de téléphonie (ITAD) présentés en figure 1 ; la figure 3 décrit le phénomène de spirale des AS se produisant lors du choix d'une route de téléphonie selon les techniques de l'art antérieur ; la figure 4 illustre la nécessité d'obtenir une synchronisation entre la couche transport et la couche service ;
Ia figure 5 décrit la nouvelle structure de base de données de routage pour un LS, selon l'invention ; - la figure 6 illustre un exemple de synchronisation réalisé à l'aide du procédé selon l'invention.
5 DESCRIPTION DETAILLEE DE L'INVENTION 5.1 Rappel du principe de l'invention
L'invention propose donc de réaliser une synchronisation entre Ia couche transfert et la couche service afin d'éviter les phénomènes de spirale d'AS et de dépréciation de la qualité de service. Le principe général de l'invention repose sur la prise en compte par un
ITAD, de nouveaux paramètres de routage liés notamment aux AS empruntés par les flux média, lors du choix d'une route servant une destination donnée. Ceci est rendu possible par la modification de la structure de la base de données de gestion des informations de routage (TRJB). On présente, en relation avec la figure 5, la nouvelle organisation des tables de routages TRIP.
« Adj-TRIBs-In » 22 : stocke les informations de routage véhiculées par des messages UPDATE. Ces infoπnations de routage, également appelées « routes », sont les entrées d'un processus de sélection 21 de routes (« Décision Process »). Un LS donné maintient une table « Adj-TRIB-In » 22 (pour adjacent TRIB in qui stocke l'ensemble d'annonces de routes reçues de la part d'un LS adjacent) par LS voisin ;
« Ext-TRIB » 24: une seule table « Ext-TRIB » (« externat TRIB ») est maintenue par LS. Cette table contient le résultat d'un processus de sélection de routes appliqué aux routes externes 25 (« Adj-TRIBs-fN ») et locales 26 (« Local Routes »). Les techniques de l'art antérieur ne peπnettent de choisir qu'une seule route par destination ; « Loc-TRIB » 20 (« Local TRIB »): cette table contient les routes locales résultant de l'application des politiques de routage locales à chaque LS ; « Adj-TRIBs-Out » 23 (« Adjacent TRlB out »): Ce sont les routes que le LS local annoncera à ses pairs.
On introduit une nouvelle table appelée « Cache Local_RIB » 27. Ce cache est fourni par le fournisseur de connectivité IP (Entité administrative gérant un AS) soit sous la forme d'un ensemble d'autorisations pour accéder aux tables de routages ou encore par l'intermédiaire d'un « looking glass » (procédé permettant de visualiser les routes IP sur les épines dorsales IP). Cette table peut être, par exemple, la copie des tables de routages (RIB,
« Route Information Base » pour « Base d'informations de route ») des ASBR
(« Autonomous System Border Router » pour « Routeurs des frontières des systèmes autonomes ») de I1AS géré par le fournisseur de service réseau IP en question.
Cette nouvelle table est utilisée, par exemple, par un processus de sélection de route TRIP afin d'assurer la synchronisation entre la couche transport et la couche Service.
5.2 Description d'un mode de réalisation Dans la version standard du protocole « TRIP », il est prévu l'échange d'informations de routage entre deux LS voisins à l'aide d'un message « UPDATE » de mise à jour. Ce message UPDATE comporte un certain nombre d'attributs. Un de ces attributs « TRIP route » contient des routes associées à des destinations données. L'art antérieur ne permet d'annoncer qu'une seule route par destination car le processus de sélection de route conventionnel ne permet de choisir qu'une seule route (dite aussi meilleure route).
A chaque « TRIP Route » on associe des attributs de route spécifiques tels que le chemin des ITAD (les deux attributs qui renseignent ce type d'information sont « AdvertisementPath » et « RoutedPath »), le prochain saut (renseigné par l'attribut « NextHopServer »), etc.
Pour permettre une synchronisation entre les deux couches Service et Transport, on implémente la procédure de configuration suivante :
Chaque ITAD dispose d'un identifiant sous forme d'un numéro d'AS ou d'une adresse IP routable ; - Cet identifiant est le même que celui utilisé par le protocole TRIP pour renseigner les attributs « AdvertisementPath » et « RoutedPath » ;
On annonce les identifiants des ITAD dans un protocole de routage inter domaines tels que BGP ou q-BGP. Ces identifiants peuvent ne pas être les vraies adresses IP des LS ; - Chaque fournisseur de service de connectivité IP (entité administrative gérant l'AS) fournit aux opérateurs de téléphonie IP (gérant un ITAD) une interface ou un cache de sa table de routage local (Cache_Local_RlB) renseignée par un protocole de routage inter domaines tel que BGP ou q- BGP. Ce cache est mis à jour à la demande des fournisseurs de service de téléphonie IP ou dynamiquement par le biais d'un autre mécanisme ;
Les spirales qui pourraient se créer au niveau IP sont éliminées au niveau de la couche service par chaque LS en activant un mécanisme d'identification des AS empruntés par une route donnée (cf. 5.4). Ainsi les routes TRJP ne contiennent plus de spirales d'AS ; Par la suite, on applique la procédure de sélection de route suivante :
A la réception d'un message « UPDATE » TRJP de la part d'un LS voisin, le LS local extrait :
Le dernier élément de l'attribut « RoutedPath » pour chaque « TRIP Route » contenu dans le message UPDATE. Cet élément est l'identifiant de l'ITAD auquel est associé le préfixe de la route en question, que l'on note ITADid. Pour toutes les routes qui servent les préfixes attachés au même ITAD, ITADid est identique ; La destination de la route, notée DEST ;
Le LS local questionne le cache de la RIB locale (c'est à dire Cache_Local_RIB) inter domaines pour trouver le chemin pour joindre
ITADid. Si une route existe, alors le LS extrait l'attribut BGP
"AS_PATH" (attribut spécifique BGP. Cet attribut renseigne la liste des domaines IP traversés par la route BGP en question) ;
Si l'attribut « AS-PATH » est de type « AS_SET » (c'est-à-dire non ordonné), le LS local cherche dans ses « Adj_TRIB_In » l'existence d'autres routes vers DEST, dont la liste des AS utilisés pour acheminer le trafic voix présentant des caractéristiques identiques aux éléments de
« I'AS_PATH ». Cette route est alors choisie par le processus de sélection de route TRIP et stockée dans la table « Local_TRIB ». Si aucune route n'existe alors le LS exécute un processus de sélection standard ou d'autres politiques locales ;
Si l'attribut ASJPATH est de type AS_SEQUENCE (c'est-à-dire ordonné), le LS extrait l'identifiant du premier AS de la liste, c'est-à-dire l'identifiant du prochain AS, noté ASid. Le LS cherche alors, parmi les routes vers DEST, contenues dans les Adj_TRIB_ln, celle dont le prochain fournisseur de connectivité IP est identique à ASid. Cette route est alors stockée dans la table « Local_TRIB ». Si aucune route n'existe alors le LS exécute un processus de sélection standard ou d'autres politiques locales ; 5.3 Exemple de mise en œuyre Pour illustrer la procédure de synchronisation, on considère l'exemple illustré par la figure 6. Supposons que l'ITADl 61 1 utilise ASl 621 pour évacuer son trafic voix, que l'ITAD2 612 utilise AS2 622, que l'ITAD3 613 utilise ASl
621 , que l'ITAD4 614 utilise AS2 622, que l'ITAD5 615 utilise AS3 623 et que l'ITADό 616 utilise AS6 626. On suppose que pour joindre D 602 à partir de S 601, le chemin d'AS choisi par un protocole de routage inter domaines est ASl, AS2, AS3, AS6 (621,
622, 623, 626). On suppose également que tous les ITAD appliquent la procédure décrite précédemment.
ITAD6 annonce ses préfixes à ITAD5 et ITAD3 ; - ITAD3 et ITAD5 ne disposent pas d'autres routes que celles reçues d'ITAD6 pour servir les préfixes d'ITADό dont D. Par conséquent, ITAD3 et ITAD5 stockent ces routes dans leurs TRlB locales et annoncent (par le biais de messages « UPDATE ») ces préfixes à ITAD4 en ce qui concerne riTAD5 et ITAD2 pour ce qui est de TITAD3 ; - La même procédure s'applique pour ITAD4 et ITAD2 à partir de FITAD3 et de riTAD5. Ces derniers propagent les préfixes d'ITAD6 vers ITADl ; ITADl reçoit deux routes pour servir les mêmes préfixes, il consulte le cache des tables de routage locales fournies par I "ASl pour trouver la route sélectionnée par le protocole de routage inter domaines vers l'identifiant d'ITADô. Cette requête retourne le chemin {AS2, AS3, AS6}. Ainsi, ITADl choisit la route TRlP reçue d'ITAD4 et la stocke dans sa table
TRIB locale.
Ainsi, les deux plans transferts et service sont synchronisés.
5.4 Mécanisme d'identification des AS empruntés par une route donnée Pour permettre les transferts de paramètres de qualité de service et la sélection de routes à qualité de service on introduit un nouvel attribut, dans lequel sont contenues des informations sur la liste des AS traversés pour acheminer le trafic voix. Plus clairement, l'invention permet à la couche service d'identifier les AS, ou opérateur de connectivité IP utilisés pour le trafic voix. La connaissance et la propagation d'une telle information au niveau d'un
LS permet alors de nombreuses applications et optimisations pour la gestion du protocole TRIP. Par exemple, dans une mise en œuvre particulière, cette information peut améliorer la qualité de service. Par ailleurs, toujours grâce à cette information, un LS possède un moyen simple et efficace pour optimiser un chemin de bout en bout pour une destination donnée. Cette même information permet de plus de détecter les anomalies, telles que les spirales IP par exemple, puisque la couche service a connaissance des AS par lesquels transitent les données.
La présente demande détaille uniquement le principe de la remontée d'informations, ou d'identifiants, relatives à la couche IP. Une liste d'identifiants relatifs à la couche IP est obtenue, pour ensuite être propagée entre les LS mis en œuvre par les ITADs.
Plus précisément, on décrit maintenant un nouvel attribut contenant un numéro d'AS. Il permet d'identifier le fournisseur de connectivité IP, au niveau de la couche transport, pour acheminer de la voix. Ce numéro est fourni à un domaine de gestion administrative (ITAD) qui la transmet à un domaine voisin.
On présente dans ce document un mode de réalisation basé sur les serveurs de localisation LS. Il est bien entendu que ce mode de réalisation n'est qu'un exemple de mise en œuvre. Notamment. l'invention peut tout à fait être implémentée en utilisant des serveurs de proximité (également appelés serveurs « Proxy »).
5.4.1 Format
Classiquement, on rappelle que le protocole TRlP est mis en œuvre par les LS (serveurs de localisation) qui propagent des routes TRIP, contenant des attributs permettant de qualifier les routes échangées.
Plus précisément, la version standard du protocole TRIP (détaillée dans le document RFC3219 de Rosenberg et al. : « Telephony Routing over IP (TRlP) » de janvier 2002) prévoit rechange d'informations de routage entre deux LS voisins via le message UPDATE, qui comporte un certain nombre d'attributs.
Afin de connaître le fournisseur de service de connectivité IP utilisé pour acheminer le trafic voix d'un ITAD, on introduit un nouvel attribut nommé ASJP ATH. Cet attribut comprend les attributs suivants :
Conditional Mandatory ; True TRIP Type Code : To be defined by IANA.
Conditional Mandatory : cet attribut indique si l'attribut en question doit être renseigné ou pas dans un message TRIP.
TRIP Type Code : identifiant unique du message TRlP en question. Cet attribut a pour but de créer et de stocker une liste des AS traversés pour joindre la destination en question. En d'autres termes, c'est un attribut de la couche service qui contient des informations, relatives à la couche transport. Il est alors propagé d'un domaine de téléphonie IP (ITAD) à un domaine de téléphonie IP voisin.
L'attribut AS_PATH est composé d'une séquence de segments, ou champs, « AS path » (chemin d'AS). Chaque segment « AS path » est composé d'un triplet <path segment type, path segment length. path segment value>, défini comme suit : chaque "path segment type" a une longueur de 1 octet qui peut prendre les valeurs suivantes :
I I I
I Valeur i Type de segment chaque « path segment length » a une longueur de 1 octet et contient le nombre d'AS contenus dans le « path segment value » ; le champ « path segment value » contient un ou plusieurs numéros d'AS. chacun codé comme un champ d'une longueur de 2 octets. Ce nouvel attribut liste donc la succession des AS traversés par les données associées à un appel.
5.4.2 Procédure
On rappelle que les opérateurs disposent chacun d'un ou plusieurs LS. Chaque LS maintient une table de routage qu'il alimente avec les annonces reçues des voisins et des LS de son propre domaine. Ces annonces sont mises à jour et redistribuées à d'autres voisins si les accords le permettent.
Selon l'invention, quand un LS propage une route TRIP qu'il a apprise dans un message UPDATE d'un autre LS voisin, on prévoit qu'il modifie le nouvel attribut AS_PATH de la route selon le type de LS auquel il doit re- propager la route, selon la procédure suivante.
Quand un LS donné annonce la route à un autre pair TRIP LS situé dans son propre ITAD, ce LS ne modifie pas l'attribut AS_PATH lié à cette route.
Si le LS à qui la route est annoncée (LS pair) n'est pas situé dans le même ITAD, deux cas de figure se présentent pour la mise à jour de l'attribut AS_PATH : si le premier segment de l'AS_PATH est de type AS_SEQUENCR, le système local ajoute le numéro de son fournisseur de service de connectivité IP comme dernier élément de la séquence ; si le premier segment de l'AS_PATH est de type AS_SET, le système local ajoute un nouveau segment de type AS_SEQUENCE au début de l'AS_PATH ; ce nouveau segment contient le numéro du domaine de son fournisseur de service de connectivité IP.
Si le LS est l'origine de l'annonce, ce dernier inclut le numéro de son fournisseur de service de connectivité IP dans l'attribut AS PATH de tous les messages UPDATE à envoyer à ses pairs TRIP situés dans les ITAD voisins. De plus, le LS inclut un AS P ATH vide dans tous les messages UPDATE à envoyer à ses pairs TRIP situés dans son propre ITAD.

Claims

REVENDICATIONS
1. Procédé de sélection d'une route de téléphonie d'au moins un flux numérique desservant une destination de téléphonie, au sein d'un premier serveur de localisation appartenant à un premier domaine de téléphonie IP déployé sur au moins un système autonome, ledit système autonome échangeant avec ses voisins des informations de routage IP désignant au moins une destination IP pour mettre à jour une table de routage IP, caractérisé en ce que ledit procédé comprend les étapes suivantes de : recherche par le premier serveur de localisation desdites informations de routage IP, lesdites informations de routage IP comprenant un identifiant d'un deuxième domaine de téléphonie IP auquel est associée ladite au moins une destination de téléphonie IP, dit identifiant de destination; sélection de ladite route de téléphonie IP pour atteindre ladite au moins une destination de téléphonie, selon un critère prédéterminé de sélection de deuxième domaine de téléphonie, en fonction dudit identifiant de destination.
2. Procédé de sélection selon la revendication 1 , selon lequel lesdites informations de routage comprennent une liste d'identifiants de systèmes autonomes traversés permettant d'atteindre la destination de téléphonie associée audit identifiant de destination, ledit procédé étant caractérisé en ce que l'étape de recherche desdites informations de routage consiste à extraire de ladite table de routage dudit système autonome ladite liste d'identifiants de systèmes autonomes traversés.
3. Procédé de sélection selon les revendications 1 et 2, caractérisé en ce qu'il comprend les étapes suivantes de : réception d'au moins un message de mise à jour de route en provenance d'un deuxième serveur de localisation, ledit message définissant au moins une route de téléphonie actualisée comprenant une liste d'identifiants de systèmes autonomes traversés et une liste de domaines de téléphonie IP traversés depuis ladite destination de téléphonie ; extraction, dans ladite liste de domaines de téléphonie IP, de l'identifiant d'un domaine de téléphonie IP auquel est associée ladite destination de téléphonie, dit identifiant de destination ; obtention d'un ensemble d'au moins une route de téléphonie, préalablement stockée au sein dudit premier serveur de localisation, desservant ladite destination de téléphonie ; recherche, au sein dudit au moins un système autonome, d'au moins une route IP dont ladite au moins une destination IP est identique audit identifiant de destination, dites routes IP recherchées ; - sélection d'une route de téléphonie, au sein dudit ensemble de routes d'acheminement de téléphonie, dont une liste de systèmes autonomes traversés comprend les mêmes identifiants de systèmes autonomes que ladite liste d'identifiants de systèmes autonomes de ladite au moins une route recherchée, lorsqu'une telle route existe ; - sélection d'une route de téléphonie dudit ensemble de routes d'acheminement de téléphonie, lorsqu'il n'existe pas de route dont une liste de systèmes autonomes traversés comprend les mêmes identifiants de systèmes autonomes que ladite liste d'identifiants de systèmes autonomes, selon au moins un critère prédéterminé ; - stockage de ladite route de téléphonie sélectionnée.
4. Procédé de sélection selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte une étape d'émission d'au moins un message de mise à jour de route vers un serveur de localisation, ledit message définissant au moins une route de téléphonie actualisée comprenant au moins un identifiant d'au moins un système autonome et au moins un identifiant d'au moins un domaine de téléphonie IP.
5. Procédé de sélection selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comporte les étapes suivantes : réception d'au moins un message de mise à jour de route en provenance d'un deuxième serveur de localisation situé dans ledit premier domaine de téléphonie, ledit message définissant au moins une route de téléphonie actualisée comprenant une liste d'identifiants de systèmes autonomes traversés et une liste de domaines de téléphonie IP traversés depuis ladite destination ; - stockage de ladite au moins une route de téléphonie actualisée,
6. Procédé de sélection selon l'une quelconque des revendications 1 à 5, caractérisé en ce ladite liste d'identifiants de systèmes autonomes est ordonnée selon au moins un critère d'ordonnancement prédéterminée, et en ce que ladite étape de sélection tient compte dudit au moins un critère d'ordonnancement prédéterminé.
7. Procédé de sélection selon l'une quelconque des revendications 1 à 6, caractérisé en ce ladite liste d'identifiants de serveurs autonomes n'est pas ordonnée, et en ce que ladite étape de sélection tient compte du premier identifiant de ladite liste d'identifiants de systèmes autonomes.
8. Dispositif de sélection d'une route de téléphonie d'au moins un flux numérique desservant une destination de téléphonie au sein d'un premier serveur de localisation appartenant à un premier domaine de téléphonie IP déployé sur au moins un système de transfert autonome, ledit système autonome échangeant avec ses voisins des informations de routage IP désignant au moins une destination IP pour mettre à jour une table de routage IP, caractérisé en ce qu'il comprend les moyens de : recherche desdites informations de routage IP, lesdites informations de routage IP comprenant un identifiant d'un deuxième domaine de téléphonie IP auquel est associée ladite au moins une destination de téléphonie IP, dit identifiant de destination; sélection de ladite route de téléphonie IP pour atteindre ladite au moins une destination de téléphonie, selon un critère prédéterminé de sélection de deuxième domaine de téléphonie, en fonction dudit identifiant de destination.
9. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution du procédé de production selon l'une au moins des revendications 1 à 7, lorsqu'il est exécuté sur un ordinateur.
10. Signal de sélection pour la mise en œuvre du procédé selon l'une quelconque des revendications 3 à 7, caractérisé en ce qu'il comprend un message de mise à jour de route comprenant des données représentatives d'une liste d'identifiants de systèmes autonomes traversés et une liste de domaines de téléphonie IP traversés depuis ladite destination.
EP07731924A 2006-04-21 2007-04-20 Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants Withdrawn EP2014031A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0603622 2006-04-21
PCT/FR2007/051149 WO2007122353A1 (fr) 2006-04-21 2007-04-20 Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP2014031A1 true EP2014031A1 (fr) 2009-01-14

Family

ID=37682036

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07731924A Withdrawn EP2014031A1 (fr) 2006-04-21 2007-04-20 Procede de selection d'une route de telephonie au sein d'un domaine de telephonie ip, dispositif et programme d'ordinateur correspondants

Country Status (3)

Country Link
US (1) US7990892B2 (fr)
EP (1) EP2014031A1 (fr)
WO (1) WO2007122353A1 (fr)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7885277B2 (en) * 2008-12-09 2011-02-08 At&T Intellectual Property I, L.P. Methods and apparatus to analyze autonomous system peering policies
US8570962B2 (en) 2010-06-22 2013-10-29 Blackberry Limited Information selection in a wireless communication system
US9385938B2 (en) * 2010-06-22 2016-07-05 Blackberry Limited Information distribution in a wireless communication system
US10230603B2 (en) * 2012-05-21 2019-03-12 Thousandeyes, Inc. Cross-layer troubleshooting of application delivery
US9729414B1 (en) 2012-05-21 2017-08-08 Thousandeyes, Inc. Monitoring service availability using distributed BGP routing feeds
US9411787B1 (en) 2013-03-15 2016-08-09 Thousandeyes, Inc. Cross-layer troubleshooting of application delivery
US10659325B2 (en) 2016-06-15 2020-05-19 Thousandeyes, Inc. Monitoring enterprise networks with endpoint agents
US10671520B1 (en) 2016-06-15 2020-06-02 Thousandeyes, Inc. Scheduled tests for endpoint agents
US11032124B1 (en) 2018-10-24 2021-06-08 Thousandeyes Llc Application aware device monitoring
US10848402B1 (en) 2018-10-24 2020-11-24 Thousandeyes, Inc. Application aware device monitoring correlation and visualization
US10567249B1 (en) 2019-03-18 2020-02-18 Thousandeyes, Inc. Network path visualization using node grouping and pagination

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
US6741585B1 (en) * 2000-05-05 2004-05-25 Lucent Technologies Inc. Interworking of addressing in an internetwork
US7072303B2 (en) 2000-12-11 2006-07-04 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks
US7002973B2 (en) * 2000-12-11 2006-02-21 Acme Packet Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via use of a cluster of session routers
US7565448B1 (en) * 2004-02-03 2009-07-21 Sprint Communications Company L.P. Network control system for a communication network
US7756998B2 (en) 2004-02-11 2010-07-13 Alcatel Lucent Managing L3 VPN virtual routing tables
US7814227B2 (en) * 2005-03-04 2010-10-12 Cisco Technology, Inc. Computation of a shortest inter-domain TE-LSP across a set of autonomous systems
US20060262776A1 (en) * 2005-05-23 2006-11-23 Pollock Graham S System and method for auto-discovery of peering and routing in a combined circuit -switched/packet-switched communication network using trip protocol
US8761155B2 (en) * 2006-04-21 2014-06-24 France Telecom Method of taking account of quality of service between distinct IP telephony domains, and a corresponding location server and computer program
WO2007122352A1 (fr) * 2006-04-21 2007-11-01 France Telecom Procede de propagation d'information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d'ordinateur correspondants
FR2900300A1 (fr) * 2006-04-21 2007-10-26 France Telecom Procede de propagation de routes de telephonie ip multiples, dispositif et programme d'ordinateur correspondants
WO2008110723A2 (fr) * 2007-02-16 2008-09-18 France Telecom Optimisation de l ' acheminement de communications entre une pluralite de domaines de telephonie

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
US7990892B2 (en) 2011-08-02
WO2007122353A1 (fr) 2007-11-01
US20090086724A1 (en) 2009-04-02

Similar Documents

Publication Publication Date Title
EP2014031A1 (fr) Procede de selection d&#39;une route de telephonie au sein d&#39;un domaine de telephonie ip, dispositif et programme d&#39;ordinateur correspondants
EP2294798B1 (fr) Procede de routage d&#39;un paquet de donnees dans un reseau et dispositif associe
EP3891935B1 (fr) Procédé de configuration d&#39;un noeud d&#39;un réseau
EP2057795B1 (fr) Procédé de propagation de routes de téléphonie ip multiples, serveur de localisation et programme d&#39;ordinateur correspondants
EP2109991B1 (fr) Optimisation de l&#39;acheminement de communications entre une pluralite de domaines de telephonie
EP3430777B1 (fr) Procédé et système de gestion dynamique de chemins de communication entre routeurs en fonction de besoins applicatifs
EP2052505A1 (fr) Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d&#39;ordinateur correspondants
FR2934450A1 (fr) Distribution de routes dans un reseau de routeurs.
WO2007122352A1 (fr) Procede de propagation d&#39;information de connectivite ip entre domaines de telephonie ip distinct, serveur de localisation et programme d&#39;ordinateur correspondants
WO2010072953A1 (fr) SYSTEME D&#39;ACHEMINEMENT D&#39;UN PAQUET DE DONNEES IPv4
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2005025146A1 (fr) Transmission de trafic multipoint au sein d’un reseau de communication
FR2872369A1 (fr) Procede de gestion d&#39;une interconnexion entre reseaux de telecommunication et dispositif mettant en oeuvre ce procede
EP2254288B1 (fr) Procédé de prévention et d&#39;évitement de boucles en inter-domaine
WO2025078594A1 (fr) Procédés de sélection de tranches réseau adaptées à un service, de gestion d&#39;au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés
EP1757073A1 (fr) Routage pour detection de serveurs au sein d&#39;un reseau de communication
Zhou et al. Discovery and composition of communication services in peer-to-peer overlays
FR2973628A1 (fr) Procedes de resolution d&#39;identifiants d&#39;abonnes, de mise a jour d&#39;une table de resolution d&#39;adresses de routeurs d&#39;acces et de mise a jour d&#39;une table de resolution d&#39;adresses ip de rattachement
WO2007063211A1 (fr) Declenchement automatique de communications
WO2007003841A2 (fr) Procede de reservation de ressources ip inter-domaines
WO2004014046A2 (fr) Procede de traduction d&#39;adresse permettant de faciliter l&#39;utilisation d&#39;un adressage de type ip «anycast»
FR2881904A1 (fr) Procede de gestion de reinitialisation de session selon un protocole de routage

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: 20081114

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090917

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

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: 20171103