EP2052505A1 - Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d'ordinateur correspondants - Google Patents

Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d'ordinateur correspondants

Info

Publication number
EP2052505A1
EP2052505A1 EP07731926A EP07731926A EP2052505A1 EP 2052505 A1 EP2052505 A1 EP 2052505A1 EP 07731926 A EP07731926 A EP 07731926A EP 07731926 A EP07731926 A EP 07731926A EP 2052505 A1 EP2052505 A1 EP 2052505A1
Authority
EP
European Patent Office
Prior art keywords
quality
service
route
telephony
domain
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
EP07731926A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Pierrick Morand
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 EP2052505A1 publication Critical patent/EP2052505A1/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
    • 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
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Definitions

  • the present invention relates to the field of telephony over Internet-type networks, by means of IP type networks (of the English "Internet Protocol” for "Internet Protocol”).
  • Telephony is understood to mean conventional telephony services, video telephony services or synchronous digital data transfer services. More specifically, the present invention is in the context of taking into account the quality of service parameters allowing entities managing telephony domains to route calls by providing an optimal quality of service.
  • the invention relates to a method for managing the quality of service between telephony domain management entities on networks implementing, for example, an IP-based communication mechanism (in English). Internet Protocol "for" Internet Protocol ").
  • IP network is the backbone adopted by operators to pool their heterogeneous service offerings including IP telephony commonly referenced by the abbreviation VoIP ("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
  • telephony offers deployed over an IP network must meet quality constraints such as high availability and high fault tolerance.
  • the availability constraint of the service does not only concern the transfer layer (OSI network / transport layers) but also the service layer.
  • LS Local Server
  • AS Automatic System
  • IP connectivity provider As part of the BGP (Border Gateway Protocol), [RFCL 771], each AS is identified by a unique identifier. This AS is also called “IP Transfer Domain”. 2 SOLUTIONS OF THE PRIOR ART
  • SDP Session Description Protocol
  • RTP Real-time Transfer Protocol
  • RTCP Real-time Transfer Protocol
  • MGCP multimedia Gateway control Protocol "to” multimedia backbone control Protocol
  • SAP session announcement Protocol "to” Memorandum of session announcement
  • TRJP Telephony Routing Over IP, [RFC3219] for "Routing IP Telephony”
  • TRlF allows interconnected ITADs to exchange all the destinations they can reach and also facilitates the selection of the most appropriate "Gateway” or "backbone” to evacuate IP telephony traffic to the nearest destination.
  • RTC network The TRIP protocol is implemented by LS ("Location Servers” for “Location Servers”) that propagate TRJP routes containing attributes to qualify the routes in question. The use of 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”).
  • TRIB Telephony Routing Information Database
  • This routing base is powered by advertisements received from neighboring LSs (from another telephony domain, for example).
  • the operation of the TRIP protocol is similar to that of the Border Gateway Protocol (BGP). Announcements between neighboring LSs are performed as route update messages, also called "UPDATE" messages. These messages are defined by the TRIP protocol and are exchanged between the LSs to info ⁇ ner a neighboring domain of the available routes.
  • BGP Border Gateway Protocol
  • each ITAD being administered by a single telephone operator.
  • These operators each have one or more LSs.
  • Each LS maintains a routing database that it feeds with advertisements received from its neighbors (located in other domains) and LSs from its own domain. These ads are updated and redistributed to other neighbors if the agreements allow.
  • FITAD4 14 updates ads received from FITAD5 15 and re-propagates them to ITAD3 13. It should be noted that an ITAD is not necessarily deployed on a single "IP transfer domain", also called an AS.
  • an LS treats three types of routes: External Routes, received from LS located in neighboring ITADs; internal routes (Internai Routes), received from LS located in the same
  • ITAD Local Routes, configured locally in each LS for injection into TRlP processes. This operation is performed either by static configuration or by redistributing information from other routing protocols.
  • 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 do not allow to choose a single route by 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 processing. QoS that will be reserved for voice streams.
  • Q-BGP QoS-Enhanced Border Gateway Protocol
  • a disadvantage of this technique of the prior art is that the problem of QoS has not been considered at the service level by the existing approaches.
  • the telephony offers rely on the transfer layer to provide the QoS processing required by the digital streams (audio and / or video) to be transferred.
  • LSs do not have dynamic and credible means for judging the QoS associated with a given route. As a result, LSs can choose paths that offer non-compliant communications to end-user and sub-optimal QoS expectations.
  • the solution proposed by the invention makes it possible to overcome these drawbacks of the prior art, by means of a method for propagating at least one route for routing at least one digital stream between a first location server of a first IP telephony domain and a second server of locating a second IP telephony domain, said first location server belonging to a first autonomous system and said second location server belonging to a second autonomous system, said method comprising a step of sending by said first message localization server updating digital flow routing routes to said second location server.
  • the propagation method is characterized in that said update messages contain quality of service management information and that said quality of service management information is updated by said first server prior to propagation to said second server based on at least one quality of service feature of said first telephony domain and / or said first autonomous system.
  • the invention is based on an entirely new approach to the propagation of routing routes in IP telephony domains, by allowing these domains to receive information as to the quality of service implemented during the transmission. routing of digital streams.
  • QoS information is contained in the route update message routing that are exchanged between location servers that make up part of the IP telephony domain. It is therefore not necessary to modify the existing hardware architectures to take into account the quality of service as an additional criterion for selecting inter-domain routes.
  • said quality of service management information comprises at least one of the following information: a quality of service component information linked to at least one autonomous system, called system component; a quality of service component information linked to at least one IP telephony domain, called domain component:
  • the information is split into two components.
  • the quality of service information exchanged can thus take into account the telephony domains and the autonomous systems responsible for the actual transfer of the IP packets, thereby ensuring consistency between the "service" layer of the telephony domain and the "transfer" layer. Managed for example by nodes composing autonomous systems.
  • said update does not modify the management information of the quality of service.
  • the location server that processes a message to be propagated can update the quality of service information contained in this message. If this message is propagated to a location server in the same domain, then the QoS information is not updated. Indeed, when two location servers belong to the same domain, the quality of service rendered by a domain can be considered as being the same in each location server of this domain.
  • said update only takes into account said least one domain component.
  • said update takes into account said at least one domain component and said at least one system component.
  • the two components of the service quality management information are used to update the quality of service associated with the routing route considered.
  • said method comprises a prior step of negotiating a quality of service management capability, according to at least one predetermined parameter between said first and second location servers so that said servers location exchange update messages containing QoS information.
  • the location servers negotiate, before any exchange of route, their respective capacities. taking into account the quality of service.
  • the location server to exchange QoS information that they are mutually adapted to take into account.
  • said method comprises a step of selecting at least one route to propagate function of said quality of service management information.
  • a location server may choose a route to propagate to another location server based on the quality of service management information that it has for a given destination.
  • the location server thus selects routes that meet the quality expectations for the transfer of digital streams from the telephony service point of view.
  • At least one of said quality of service parameters is a mandatory quality of service parameter
  • said selection step takes into account said at least one mandatory quality of service parameter
  • said at least one quality of service parameter has a hierarchy level, and said selection step takes into account said hierarchy level.
  • these service quality parameters also include hierarchy levels. These levels are independent of the mandatory and / or optional nature of the parameters. They allow to prioritize the parameters when selecting the route to propagate. Thus some parameters can be considered before others when selecting the route to install in the local routing tables and therefore the one to propagate to other peers.
  • the invention also relates to a location server of a first IP telephony domain, able to propagate at least one routing route of at least one digital stream to a second location server of a second IP telephony domain, said first location server belonging to a first autonomous system and said second location server belonging to a second autonomous system, said first location server comprising means for sending update messages of digital flow routing routes to said second location server, characterized in that said update messages contain quality of service management information, and that said quality of service management information is set to by said first server before propagation to said second server based on at least one feature of said first telephony domain and / or said first autonomous system.
  • Such a location server makes it possible to convey quality of service management information between the IP telephony domains.
  • such a location server comprises means for implementing the steps of the method of propagation of at least one routing route.
  • 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 comprises program code instructions for the execution of the propagation process of at least one conveying route as described above.
  • FIG. 1 presents an example of architecture of domains of telephony (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;
  • Figure 3 illustrates the format of a "Capability"attribute;
  • FIG. 7 is a flow chart showing a route selection algorithm according to a first embodiment
  • FIG. 8 is a flowchart illustrating an algorithm taking route selection according to a second embodiment.
  • the following is an embodiment of the invention implementing the TRIP protocol at the service layer.
  • the invention is not limited to this particular protocol, but can also be applied to any new protocol for exchange of routes between IP telephony domains.
  • the present invention incorporates two major aspects. First, it presents a new technique for the exploitation of information by the service layer as regards the quality of effective service at the transfer level. Then, it introduces two new and optimal route selection processes for optimal quality of service.
  • the invention therefore proposes a technique for optimizing inter-domain quality of service based on QoS information exchanged between telephony domains.
  • QoS information will be referred to later as the actual service quality information at the data transfer layer.
  • LSs can select the best path that offers the desired QoS to establish a given communication.
  • the RFC3219 standard (described in the RFC3219 document by Rosenberg et al. : "Telephony Routing over IP (TRIP)" of January 2002) suggests to exchange during the opening of the TRIP session the "Capabilities" of each LS, and to exchange only the attributes supported by the two peer LSs communicating with each other.
  • TRIP Transmission Control Routing over IP
  • the new "QoS Route Capability" attribute is intended to inform the different LSs of the support of routes containing QoS information by the TRIP instance when opening the TRlP session. Without this negotiation phase, the TRIP session may be closed if an LS peer sends "TRIP Route” messages that do not conform to the format defined in the RFC3219 standard. Once the Capabilities negotiation phase is successful, two LS peers can exchange UPDATE messages with modified "TRIP Route" attributes. Therefore, the TRIP protocol will support routes including QoS information.
  • the modified "TRIP Route” attribute indicates the QoS values associated with the route in question. These values serve to inform the neighboring LS, and thus to propagate the quality of the service associated with a given route.
  • a route denotes a list of destination addresses (each address is defined by an AFl (Adress Family Indicator) and a prefix) associated with an application protocol such as SIP or H.323.
  • Each route is associated with a set of attributes such as "NextHopServer”, "AdvertisementPath” and “RoutedPath”. whose meaning of these attributes is detailed in RFC3219 respectively in paragraphs 5.3, 5.4. 5.5. These attributes serve to guide the choice of road to be installed in the TRIBs. 5.2 Description of the new QoS attributes
  • LSs In order to select an ITAD path that offers better QoS guarantees, LSs must have access to QoS information. Two modes can be envisaged: either the QoS information is exchanged in TRJP, or the LS consults the q-BGP routing tables. In this embodiment, an exchange of QoS information related to the TRIP protocol is presented.
  • the new attribute "Capability” according to the invention that is to say “QoS Route Capability” is exchanged at the start of a TRIP session. So that it conforms to the specification of the TRIP protocol and therefore agreed during the negotiation phase, it presents a "classic” format as shown in Figure 3. This attribute is optional Note that is is not necessarily supported by all TRlP implementations.
  • a first field 31 "Capability Code”, a length of two bytes contains a code identifying the "Capability”
  • a second field 32 “Capability Length”, also two bytes long, contains the length of the "Capability”
  • a third field 33 “Capability Value”, whose size is variable, contains the value of the "Capablity”.
  • Capability Code is equal to 4.
  • LS peer contains a series of fields 41, 43 "Address Family” and fields 42, 44 "Application Protocol". each of these two fields having a size of two bytes.
  • An LS peer can tell its neighbors which types of addresses are supported and which will be used when valuing TRIP route fields.
  • One or more couples (“Address Family", "Application Protocol") can be entered.
  • a first pair 420 is formed of fields 41 and 42 and a second pair 430 is formed of fields 43 and 44 for example.
  • RFC3219 The current specification (RFC3219) of the TRIP protocol does not allow to announce QoS information.
  • the format of the "TRlP Route” attribute defined by RFC3219 is illustrated in Figure 5. It contains four fields 51, 52, 53 and 54, respectively corresponding to
  • the first three fields 51, 52 and 53 have a size of two bytes while the last field 54 is of variable size.
  • the "TRIP Route” attribute is modified as illustrated by FIG. 6.
  • field 61 QoS Information length
  • field 62 QoS Information Code
  • field 63 QoS Information Sub-Code
  • field 64 QoS Information Value
  • fields 62, 63 and 64 are repeated according to a number of quality of service parameters supported by the route; a field 71 "Address family” of a length of two bytes; a field 72 “Application Protocol” with a length of two bytes; a field 73 “Length” of a length of two bytes; a field 74 "Address” of variable length.
  • the fields "Address Family”, “Application Protocol”, “Length” and “Address” are defined in section 5.1.1.1 of RFC3219, and reported in the appendix of this description.
  • the new fields according to the invention have the following meanings: the field “QoS Information length” indicates the number of QoS information codes (ie the number of QoS parameters) sent by an LS in an UPDATE message to its neighbor LSs (peers); the "QoS Information Code” field indicates the type of QoS information entered in the "QoS Information value” field. This field can take the following values:
  • the "QoS Information Sub-Code” field indicates the subtype of the QoS information entered in the "QoS Information value” field. . This field can take the following values: (O) "None” - (1) "Reserved rate”
  • QoS Information value indicates the value of the QoS information.
  • the unit of this field depends on the type of the QoS information code.
  • an LS announces routes including QoS information by sending an UPDATE message containing modified "TRIP Route" attributes, as described in the previous section, to its peer / neighbor LSs.
  • Each TRIP Route is associated with specific route attributes such as the ITAD path (the two attributes that inform this type of information are
  • an LS When an LS receives TRIPs in an UPDATE message from a neighboring LS, it is able to modify the QoS information contained in the modified "TRIP Route" attribute according to the type of LS from which it received the routes in question. : when a given LS receives the route of another peer LS located in its own ITAD, this LS does not modify the "TRIP Route”attribute; - when an LS receives the route of a peer LS located in another neighboring ITAD, then that LS may update the "TRIP Route” attribute as follows: if the neighboring ITAD uses the same IP connectivity service provider to evacuate the voice traffic (this information is contained in the AS_PATH attribute defined in the following section), then this LS updates the information contained in the attribute "TRIP Route” modified taking into account only the service part and not the QoS information relating to the transport part. This update is described later, if the neighboring ITAD does not use the same IP connectivity service provider to evacuate voice traffic, then this LS updates the information contained
  • an LS When an LS is the origin of the announcement, it values the QoS information in the "TRIP Route" attribute modified with QoS features including both service and transfer layers.
  • the valuation of the QoS information relating to the transfer layer can be carried out according to two approaches. According to a first implementation, it is possible to take into account only the local information provided by the IP network service provider to the telephony operator. According to a second approach, it is possible to rely on QoS information conveyed by a protocol such as q-BGP [QBGP], of the transport layer (also called IP layer).
  • QBGP q-BGP
  • This information from the IP layer for example through the q-BGP protocol, can be static or dynamic:
  • This QoS information is said to be static if its values do not change over time. The value of this type of information is statically indicated in a system. This information is provided to the IP Telephony Operator in the form of a Service Agreement containing QoS (i.e. "SLA" of Service Level
  • Said system component is statically linked to the at least one autonomous system, according to at least one predetermined service level agreement; In this case, a service level agreement is associated with each autonomous system. The quality of service of this autonomous system is therefore considered to be constant / static.
  • the SLA is statically negotiated between the autonomous systems that make up the network and provided to the IP telephony domain.
  • IP telephony operator can then have access to the dynamic values using an interface made available by the IP connectivity provider (ie TAS manager in which the elements of the telephony domain are deployed) which has implemented implement appropriate mechanisms such as measurement and monitoring tools to judge the IP performance of its own AS.
  • IP connectivity provider ie TAS manager in which the elements of the telephony domain are deployed
  • the system component is dynamically linked to the at least one autonomous system through an IP connectivity interface, associating said first location server and said first autonomous system.
  • the system component is dynamic and therefore varies over time. It is therefore accessible to the telephony domains by means of an interface enabling a localization server of the telephony domain to know at a given moment the level of quality of service rendered by the autonomous system on which it is based through several quality of service parameters.
  • the quality of service information handled by the location servers contains two components:
  • this component only informs the QoS parameters concerning the telephony service platform. For example: the average time required for call processing in telephony is 5ms, the maximum time required for call processing in telephony servers is 1 Oms.
  • the transport part concerns the values of the QoS parameters provided by the IP connectivity provider (described above, which can be dynamic or static). For example: the average time required to cross the AS is 50ms, the maximum delay required to cross the AS is 100ms.
  • the value of a QoS parameter is equal to the sum of the service component and that of the transfer.
  • the average time required for call processing is
  • the operation of modifying the QoS information contained in the TRJP messages consists in concatenating the values of the local QoS parameters of the domain receiving the TRIP announcement with those already contained in the route announcement (ie those contained in in the "UPDATE" message).
  • the concatenation method depends on the nature of the QoS parameter in question. For example, the additive QoS parameters and the multiplicative QoS parameters may be mentioned.
  • the result of the concatenation operation is the addition of the local value of the parameter concerned and that already contained in the route announcement message received from a neighboring LS.
  • a new attribute is introduced, which contains information about IP connectivity service providers used to route voice traffic. More clearly, the service layer is allowed to identify ASs, or IP connectivity operators used for voice traffic. An LS then 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 TRIP protocol is implemented by the LS (location servers) that propagate TRlP routes, containing attributes to qualify the routes in question.
  • the standard version of the TRIP protocol (detailed in Rosenberg et al .: RFC3219: "Telephony Routing over IP (TRIP)" of January 2002) provides for the exchange of routing information between two neighboring LSs via the message.
  • UPDATE which has a number of attributes.
  • AS_PATH In order to know the list of IP connectivity service providers used to route the voice traffic of an ITAD, a new attribute named AS_PATH is introduced. This attribute includes the following attributes:
  • TRIP Type Code To be defined by IANA.
  • 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 AS PATH attribute is composed of a sequence of segments, or fields, "AS path".
  • Each "AS path” segment is composed of a ⁇ path segment type> triplet, 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 "path segment value" field contains one or more AS numbers, each encoded as a field of 2 bytes long.
  • This new attribute therefore lists the succession of crossed ASs to join a given destination.
  • Each LS maintains a routing table that it feeds with advertisements received from neighboring LSs and those from its own domain. These ads are updated and redistributed to other neighbors if interconnection agreements allow.
  • the advertisement includes the IP connectivity service provider 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_PATH in all UPDATE messages to send to its TRIP peers located in its own ITAD.
  • the inventors have found that it is desirable that the TRIP inter ITAD route selection processes must take into account the quality of service information. to guide the selection of the route to be stored in the TRlP routing databases. Therefore, the route selection process as described in RFC3219 is no longer appropriate since it does not take into account these quality of service criteria.
  • an IP telephony operator assigns priorities to each QoS parameter advertised in TRIP messages. For example, an operator can assign the "Minimum one way delay” parameter (for “minimum path delay”) to a higher priority, and a lower priority to the "Loss” parameter. Rate “(for” loss rate ”) and so on. Prioritization can also be carried out by a standardization body such as HETF (for the "Internet Engineering Task Force") or PITU (for "International Telecommunication Union”).
  • HETF for the "Internet Engineering Task Force”
  • PITU for "International Telecommunication Union”
  • the algorithms presented hereinafter are based on this prioritization principle for the QoS parameters conveyed in the TRIP messages, in particular in the modified "TRlP Route” attributes according to the procedure described in paragraph 5.2 of the present description. 5.4.1 Algorithm 1
  • the algorithm illustrated in Figure 7, for the selection of TRIP routes takes into account the information of QoS exchanged by TRIP and installs them in the local TRIB.
  • step 93 the algorithm performs a step 93 of storing that route in the local TRIB. If more than one route is returned (ii), a step 92 "excludes" the Quality of Service performance characteristic that is used in step 91 of the Quality of Service performance characteristics list. a) If, as a result of this "exclusion" step 92, there is no remaining Quality of Service performance characteristic, the conventional TRIP route selection method is performed, in a step 94, if more a route was identified in step 90; b) Otherwise, the algorithm repeats step 91. 5.4.2 Algorithm 2
  • Optional is a category in which optional QoS information is grouped that may be populated by a neighbor LS in its UPDATE messages. If a TRlP ad does not contain a QoS parameter of this type, this ad is not deleted.
  • the invention proposes a new algorithm taking into account this hierarchical level for an optimal route selection in terms of end-to-end Quality of Service.
  • the route being checked is added to the list of remaining routes in a step 1 1 10. If no, this roll is discarded (step 1 120). The remaining routes are then examined in a step 120.
  • a step 1200 examines the highest priority QoS performance characteristic and returns the routes that optimize this QoS performance characteristic: a) if a single route is returned, a step 1210 stores this route in the local TRLB; b) if more than one route is returned, a step 1220 excludes the Quality of Service performance characteristic that was used in step 1200 of the Quality of Service performance characteristics list.
  • step 1220 if no Quality of Service performance characteristics remain, the conventional TRIP route selection method is implemented (step 130), if more than one route has been returned, when from step 100.
  • step 1200 is repeated.
  • step 120 if the number of remaining routes is zero, the algorithm executes the conventional TRIP route selection method in step 130, provided that more than one route has been returned when step 100.
  • Length The length of the "Address" field, in bytes
  • Address Corresponds to an address (prefix) of the given family type identified by the Address Family field.
  • the length in bytes of the address is variable and is determined by the field length of the route.

Landscapes

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

Abstract

L'invention concerne un procédé de propagation d'au moins une route d'acheminement d'au moins un flux numérique entre un premier serveur de localisation d'un premier domaine de téléphonie IP et un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un premier système autonome et ledit deuxième serveur de localisation appartenant à un deuxième système autonome, ledit procédé comprenant une étape d'envoi de messages de mise à jour de routes d'acheminement de flux numériques audit deuxième serveur de localisation. Selon l'invention, lesdits messages de mise à jour contiennent des informations de gestion de la qualité de service et lesdites informations de gestion de la qualité de service sont mises à jour par ledit premier serveur avant propagation vers ledit deuxième serveur en se basant sur au moins une caractéristique de qualité de service dudit premier domaine de téléphonie et/ou dudit premier système autonome.

Description

Procédé de prise en compte de la qualité de service entre domaines de téléphonie IP distincts, serveur de localisation 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 le biais de réseaux de type IP (de l'anglais « Internet Protocol » pour « Protocole Internet »). Par téléphonie, on entend tout aussi bien les services de téléphonie classiques, les services de visiophonie ou les services de transfert de données numériques synchrones. Plus précisément, la présente invention se place dans le cadre de la prise en compte des paramètres de qualité de service permettant à des entités de gestion de domaines de téléphonie d'acheminer des appels en offrant une qualité de service optimale.
En particulier, l'invention concerne une méthode de gestion de la qualité de service entre des entités de gestion de domaines de téléphonie sur des réseaux mettant en œuvre, par exemple, un mécanisme de communication basé sur le protocole IP (de l'anglais « Internet Protocol » pour « Protocole Internet »).
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 Ia 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 voix 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 transfert (couches réseau/transport OSI) mais également la couche service.
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 Ia 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 », [RFCl 771 ]), chaque AS est identifié par un identifiant unique. Cet AS est également appelé « Domaine de Transfert IP ». 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ématiquement 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 pays 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 réseau « IP ». Pour accompagner le déploiement de services de « VoIP », I1IETF (« 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 TRJP (Telephony Routing Over IP, [RFC3219] pour « Routage de la téléphonie sur 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.
TRlF permet à des ITAD interconnectés d'échanger l'ensemble des destinations qu'ils peuvent joindre et facilite aussi la 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 TRJP 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 la 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, également nommés messages « UPDATE ». Ces messages sont définis par le protocole TRIP et sont échangés entre les LS pour infoπner un domaine voisin des routes disponibles.
On décrit, en relation avec la figure 1, l'activation du protocole TRIP 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. 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 (situés dans d'autres domaines) et des LS de son propre domaine. Ces annonces sont mises à jour et redistribuées à d'autres voisins si les accords le permettent.
Ainsi FITAD4 14, par exemple, met à jour les annonces reçues de FITAD5 15 et les re-propage à ITAD3 13. II convient de noter qu'un ITAD n'est pas nécessairement déployé sur un seul « domaine de transfert IP», également appelé un AS.
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.
Ainsi, quatre types de « TRlB » 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 (de l'anglais « Décision Process »). Un LS donné maintient une table « Adj- TRlB-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: Seule 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 Fart antérieur ne permettent de choisir 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 Ie LS local annoncera à ses pairs. Dans la couche transfert, (couche chargée du transfert effectif des appels), 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. Dans l'état actuel des techniques de l'art antérieur, il n'existe aucun mécanisme de gestion de la qualité de service entre les opérateurs de téléphonie sur IP.
2.2 Inconvénients de l'art antérieur
Un inconvénient de cette technique de l'art antérieur est que la problématique de la QoS n'a pas été considérée au niveau service par les approches existantes. Les offres de téléphonie, s'appuient sur la couche transfert pour assurer le traitement de QoS requis par les flux numériques (audio et/ou vidéo) à transférer.
Or il n'existe pas de moyens pour corréler (dynamiquement) les deux couches (service, pour les ITAD via le protocole TRlP par exemple et transfert pour les AS, via le protocole BGP par exemple). Une corrélation peut être mise en place, mais elle nécessite une configuration de routes statiques. En effet, le protocole TRIP ne définit pas d'attribut qui permette de faciliter la corrélation avec le protocole « q-BGP » et les informations de QoS que ce dernier propage entre différents routeurs de bordure.
Un autre inconvénient de cette technique de l'art antérieur est que les LS ne disposent pas de moyens dynamiques et crédibles pour juger la QoS associée à une route donnée. De ce fait, les LS peuvent choisir des chemins qui offrent des communications non conformes aux attentes de QoS des clients finaux et non optimaux.
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 propagation d'au moins une route d'acheminement d'au moins un flux numérique entre un premier serveur de localisation d'un premier domaine de téléphonie IP et un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un premier système autonome et ledit deuxième serveur de localisation appartenant à un deuxième système autonome, ledit procédé comprenant une étape d'envoi par ledit premier serveur de localisation de messages de mise à jour de routes d'acheminement de flux numériques audit deuxième serveur de localisation.
Selon l'invention, le procédé de propagation est caractérisé en ce que lesdits messages de mise à jour contiennent des informations de gestion de la qualité de service et en ce que lesdites informations de gestion de la qualité de service sont mises à jour par ledit premier serveur avant propagation vers ledit deuxième serveur en se basant sur au moins une caractéristique de qualité de service dudit premier domaine de téléphonie et/ou dudit premier système autonome.
Ainsi, l'invention repose sur une approche tout à fait nouvelle de la propagation de routes d'acheminement dans des domaines de téléphonie IP, en permettant à ces domaines de recevoir des informations quant à la qualité de service mise en œuvre lors de l'acheminement de flux numériques. Ces informations de qualité de service sont contenues dans les messages de mise à jour de route d'acheminement qui sont échangés entre les serveurs de localisation qui composent en partie les domaines de téléphonies IP. Il n'est donc pas nécessaire de modifier les architectures matérielles existantes pour prendre en compte la qualité de service comme critère additionnel de sélection de routes inter-domaines.
Selon une caractéristique originale de l'invention, lesdites informations de gestion de qualité de service comprennent au moins une des informations suivantes : une information composante de qualité de service liée à au moins un système autonome, dite composante de système ; une information composante de qualité de service liée à au moins un domaine de téléphonie IP, dite composante de domaine : Les informations sont scindées en deux composantes. Les informations de qualité de service échangées peuvent ainsi tenir compte des domaines de téléphonie et des systèmes autonomes se chargeant du transfert effectif des paquets IP, assurant par la même occasion une cohérence entre la couche « service » du domaine de téléphonie et la couche « transfert » gérée par exemple, par des nœuds composant les systèmes autonomes.
Selon un aspect particulier de l'invention, lorsque ledit premier domaine de téléphonie IP et ledit deuxième domaine de téléphonie IP sont identiques, ladite mise à jour ne modifie pas les informations de gestion de la qualité de service.
Ainsi, lors du transfert des messages de mise à jour de route entre les serveurs de localisation, le serveur de localisation qui traite un message à propager peut mettre à jour les informations de qualité de service contenues dans ce message. Si ce message est propagé à un serveur de localisation se situant dans le même domaine, alors les informations de qualité de service ne sont pas mises à jour. En effet, lorsque deux serveurs de localisation appartiennent à un même domaine, la qualité de service rendue par un domaine peut être considérée comme étant la même dans chaque serveur de localisation de ce domaine.
Selon une caractéristique particulière de l'invention, lorsque ledit premier domaine de téléphonie IP et ledit deuxième domaine de téléphonie IP sont distincts et que ledit premier système autonome et ledit deuxième système autonome sont identiques, ladite mise à jour ne prend en compte que ladite au moins une composante de domaine.
En effet, lorsque les systèmes autonomes empruntés pour joindre les domaines de téléphonie différents auxquels appartiennent deux serveurs de localisation sont identiques, la qualité de service offerte au niveau transfert ne varie pas. Ainsi, une route qui emprunte deux domaines de téléphonie différents, mais un seul système autonome subira la qualité de service liée aux domaines de téléphonie, mais celle rendue lors du transfert des paquets IP est celle rendue par le système autonome. La mise à jour ne tient donc compte que de la composante de domaine, qui est la seule à varier dans ce cas de figure.
Selon un aspect particulier de l'invention, lorsque ledit premier domaine de téléphonie IP et ledit deuxième domaine de téléphonie IP sont distincts et que ledit premier système autonome et ledit deuxième système autonome sont distincts, ladite mise à jour prend en compte ladite au moins une composante de domaine et ladite au moins une composante de système.
Ainsi, dans le cas d'une route traversant plusieurs domaines de téléphonie et plusieurs systèmes autonomes, les deux composantes des informations de gestion de la qualité de services sont utilisées pour mettre à jour la qualité de service associée à la route d'acheminement considérée.
Selon une caractéristique particulière de l'invention, ledit procédé comprend une étape préalable de négociation d'une capacité de gestion de qualité de service, selon au moins un paramètre prédéterminé entre ledit premier et ledit deuxième serveurs de localisation de telle sorte que les desdits serveurs de localisation échangent des messages de mise à jour contenant des informations de qualité de service..
Afin de rendre possible l'échange d'information de qualité de service entre les serveurs de localisation et par la même occasion de rendre ces informations disponibles pour les domaines de téléphonie, les serveurs de localisation négocient, avant tout échange de route, leurs capacités respectives de prise en compte de la qualité de service. Ainsi, on s'assure que le serveur de localisation échangent des informations de qualité de service qu'ils sont mutuellement aptes à prendre en compte.
Selon une caractéristique originale de l'invention ledit procédé, comprend une étape de sélection d'au moins une route à propager en fonction desdites informations de gestion de la qualité de service.
Ainsi, un serveur de localisation peut choisir une route à propager à un autre serveur de localisation en fonction des informations de gestion de qualité de service dont il dispose pour une destination donnée. Le serveur de localisation sélectionne ainsi des routes qui correspondent aux attentes de qualité pour le transfert des flux numériques du point de vue de service de téléphonie.
Selon une caractéristique particulière de l'invention au moins un desdits paramètres de qualité de service est un paramètre de qualité de service obligatoire, et ladite étape de sélection tient compte dudit au moins un paramètre de qualité de service obligatoire.
Ainsi, lorsque ces paramètres sont obligatoires, la sélection de la route à propager tiendra compte de la présence et de la valeur de ces paramètres obligatoires.
Selon un aspect particulier de l'invention, ledit au moins un paramètre de qualité de service présente un niveau de hiérarchie, et ladite étape de sélection tient compte dudit niveau de hiérarchie.
Conjointement à leur nature composite, ces paramètres de qualité service comprennent également des niveaux de hiérarchie. Ces niveaux sont indépendants du caractère obligatoire et/ou optionnel des paramètres. Ils permettent de prioriser les paramètres lors de la sélection de la route à propager. Ainsi certains paramètres peuvent être considérés avant d'autres lors de la sélection de la route à installer dans les tables de routage locales et par conséquent de celle à propager à d'autres pairs.
L'invention concerne également un serveur de localisation d'un premier domaine de téléphonie IP, apte à propager au moins une route d'acheminement d'au moins un flux numérique vers un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un premier système autonome et ledit deuxième serveur de localisation appartenant à un deuxième système autonome, ledit premier serveur de localisation comprenant des moyens d'envoi de messages de mise à jour de routes d'acheminement de flux numériques audit deuxième serveur de localisation, caractérisé en ce que lesdits messages de mise à jour contiennent des informations de gestion de la qualité de service, et en ce que lesdites informations de gestion de la qualité de service sont mises à jour par ledit premier serveur avant propagation vers ledit deuxième serveur en se basant sur au moins une caractéristique dudit premier domaine de téléphonie et/ou dudit premier système autonome.
Ainsi, un tel serveur de localisation permet de véhiculer des informations de gestion de la qualité de service entre les domaines de téléphonie IP.
Plus généralement, un tel serveur de localisation comprend des moyens de mise en œuvre des étapes du procédé de propagation d'au moins une route d ' acheminement.
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 propagation d'au moins une route d'acheminement tel que décrit précédemment. 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 illustre le format d'un attribut « Capability »; la figure 4 illustre le format du champ « Capability Value » du nouvel attribut « QoS Route Capability » spécifique à l'invention ; - la figure 5 présente le format conventionnel de l'attribut « TRIP Route »; la figure 6 présente le format de l'attribut « TRlP Route » modifié selon
T invention ; la figure 7 est un organigramme présente un algorithme de sélection de route selon un premier mode de réalisation; - la figure 8 est un organigramme illustrant un algorithme prenant de sélection de route selon un second mode de réalisation. 5 DESCRIPTION DETAILLEE DE L'INVENTION
Pour plus de clarté, on présente ci-après un mode de réalisation de l'invention mettant en œuvre le protocole TRIP au niveau de la couche service. Cependant, il est clair que l'invention ne se limite pas à ce protocole particulier, mais peut également s'appliquer à tout nouveau protocole d'échange de routes entre domaines de téléphonie IP.
5.1 Généralités
La présente invention intègre deux aspects majeurs. Tout d'abord, elle présente une technique nouvelle d'exploitation d'information par la couche service quant à la qualité de service effective au niveau transfert. Ensuite, elle introduit deux procédés nouveaux et optimaux de sélection de la route pour une qualité de service optimale.
En d'autres termes, elle gère la qualité de service du protocole de routage de la téléphonie, par exemple « TRJP » et offre des fonctionnalités de sélection des routes à qualité de service.
L'invention propose donc une technique d'optimisation de la qualité de service inter domaines en se basant sur des informations de QoS échangées entre domaines de téléphonie. On parlera par la suite d'informations de QoS pour désigner ces informations relatives à la qualité de service effective au niveau de la couche de transfert des données.
Grâce à ces informations, les LS peuvent sélectionner le meilleur chemin qui offre la QoS voulue afin d'établir une communication donnée.
Afin d'éviter la clôture de sessions TRlP à cause d'échange d'attributs ou de messages non-conformes à la RFC TRIP, la norme RFC3219 (décrite dans le document RFC3219 de Rosenberg et al. : « Telephony Routing over IP (TRIP) » de janvier 2002) suggère d'échanger durant l'ouverture de la session TRIP les « capacités » (« Capabilities ») de chaque LS, et de ne s'échanger que les attributs supportés par les deux LS pairs communiquant entre eux. Ainsi chaque LS informe son voisin des options qu'il supporte, et ce dernier ne doit en aucun cas lui envoyer des messages qui ne peuvent être interprétés correctement par son voisin. Dans le cas contraire, la session TRIP est clôturée.
Dans le cadre de cette invention, on introduit un nouvel attribut « Capability » TRIP dénoté « QoS Route Capability » et un nouveau format de l'attri but « TRlP Route » .
Le nouvel attribut « QoS Route Capability » a pour but d'informer les différents LS du support des routes contenant des informations de QoS par l'instance TRIP lors de l'ouverture de la session TRlP. Sans cette phase de négociation, la session TRIP risque d'être clôturée si un pair LS envoie des "TRIP Route" non conformes au format définit dans la norme RFC3219. Une fois la phase de négociation des "Capabilities" réussie, deux pairs LS peuvent s'échanger des messages UPDATE contenant des attributs "TRIP Route" modifiés. Par conséquent, le protocole TRIP supportera des routes incluant des informations de QoS. L'attribut « TRIP Route » modifié indique quant à lui les valeurs de QoS associées à la route en question. Ces valeurs servent à informer le LS voisin, et donc à propager la qualité du service associée à une route donnée. On note que, dans la terminologie TRIP, une route dénote une liste d'adresses de destination (chaque adresse est définie par un AFl (Adress Family Indicator) et un préfixe) associée à un protocole applicatif tel que SIP ou H.323. A chaque route est associé un ensemble d'attributs tels que le « NextHopServer », « AdvertisementPath » et « RoutedPath ». dont la signification de ces attributs est détaillée dans le document RFC3219 respectivement dans les paragraphes 5.3, 5.4. 5.5. Ces attributs servent à orienter Ie choix de la route à installer dans les TRIB. 5.2 Description des nouveaux attributs de QoS
Afin de sélectionner un chemin d'ITAD qui offre de meilleures garanties de QoS, les LS doivent avoir accès à des informations de QoS. Deux modes peuvent être envisagés: soit les informations de QoS sont échangées dans TRJP, soit le LS consulte les tables de routage q-BGP. On présente, dans ce mode de réalisation, un échange d'information de QoS liée au protocole TRIP.
5.2.1 « QoS Route Capability »
Conformément à la procédure TRIP conventionnelle, le nouvel attribut « Capability » selon l'invention, c'est-à-dire « QoS Route Capability » est échangé au démarrage d'une session TRIP. De façon à ce qu'il soit conforme à la spécification du protocole TRIP, et donc accepté lors de la phase de négociation, il présente un format « classique » illustré par la figure 3. On note que cet attribut est optionnel est n'est pas forcément supporté par toutes les implémentations TRlP. II contient trois champs 31, 32 et 33: un premier champ 31 « Capability Code», d'une longueur de deux octets contient un code identifiant la « Capability »; un second champ 32 « Capability Length », d'une longueur de deux octets également, contient la longueur de le « Capability » ; - enfin, un troisième champ 33 « Capability Value », dont la taille est variable, contient la valeur de la « Capablity ».
Pour éviter les erreurs lors d'échanges de messages UPDATE contenant des attributs « TRIP Route » modifiés, éviter la clôture des sessions TRIP et indiquer aux pairs d'un LS donnés le support des routes avec informations de QoS, on introduit une nouvelle « Capability » dénotée « QoS Route Capability » dont le
« Capability Code » est égal à 4.
Le format du champ « Capability Value » 33 de l'attribut « Capability Information » spécifique au « QoS Route Capability » est illustré par la figure 4.
Il contient une série de champs 41 , 43 « Address Family » (Famille d'adresse) et de champs 42, 44 « Application Protocol » (Protocole d'application). chacun de ces deux champs présentant une taille de deux octets. Un pair LS peut indiquer à ses voisins les types d'adresses supportées et qui seront utilisées lors de la valorisation des champs des routes TRIP. Un ou plusieurs couples (« Address Family », « Application Protocol ») peuvent être renseignés. En relation avec la figure 4, un premier couple 420 est formé des champs 41 et 42 et une second couple 430 est formé des champs 43 et 44 par exemple.
Les significations des champs 41 , 42, 43, 44 « Address Family » et « Application Protocol » sont les mêmes que celles décrites dans la section 5.1.1 de la RFC3219, et reprises en annexe, ladite annexe faisant partie intégrante de la présente description.
5-2.2 L'attribut "TRIP Route" modifié
La spécification actuelle (RFC3219) du protocole TRIP ne permet pas d'annoncer des informations de QoS. Le format de l'attribut « TRlP Route » définit par la RFC3219 est illustré par la figure 5. II contient quatre champs 51, 52, 53 et 54, correspondant respectivement à
« Address Family », « Application Protocol », « Length » et enfin « Address ». Les trois premiers champs 51, 52 et 53 présentent une taille de deux octets alors que le dernier champ 54 est de taille variable.
Selon l'invention, afin de permettre d'annoncer les routes TRlP incluant des informations de QoS, l'attribut "TRIP Route" est modifié comme illustré par la figure 6.
Il contient plusieurs champs, numérotés de 61 à 74, et dont la nomination et la taille sont les suivantes : le champ 61 « QoS Information length » d'une longueur d'un octet ; - le champ 62 « QoS Information Code » d'une longueur de quatre bits (un demi octet) ; le champ 63 « QoS Information Sub-Code » d'une longueur de quatre bits ; le champ 64 « QoS Information Value » d'une longueur de deux octets ; les champs 62, 63 et 64 sont répétés en fonction d'un nombre de paramètres de qualité de service supportés par la route ; un champ 71 « Address family » d'une longueur de deux octets ; un champ 72 « Application Protocol » d'une longueur de deux octets ; - un champ 73 « Length » d'une longueur de deux octets ; un champ 74 « Address » d'une longueur variable.
Les champs « Address Family », « Application Protocol », « Length » et « Address » sont définis dans la section 5.1.1.1 de la norme RFC3219, et reportés en annexe de la présente description. Les champs nouveaux selon l'invention ont les significations suivantes: le champ "QoS Information length" indique le nombre de codes d'informations de QoS (i.e. le nombre de paramètres de QoS) envoyés par un LS dans un message UPDATE à ses LS voisins (pairs) ; le champ "QoS Information Code" indique le type de l'information de QoS renseignée dans le champ "QoS Information value". Ce champ peut prendre les valeurs suivantes :
(0) « Reserved »
(1) « Packet rate »
(2) « One-way delay metric » - (3) « Inter-packet delay variation » le champ "QoS Information Sub-Code" indique le sous-type de l'information de QoS renseignée dans le champ " QoS Information value ". Ce champ peut prendre les valeurs suivantes: (O) « None » - (1) « Reserved rate »
(2) « Available rate »
(3) « Loss rate »
(4) « Minimum one-way delay »
(5) « Maximum one-way delay » - (6) « Average one-way delay » le champ "QoS Information value" indique la valeur de l'information de QoS. L'unité de ce champ dépend du type du code de l'information de QoS.
5.2.3 Procédure On rappelle que la version standard du protocole TRIP prévoit l'échange d'informations de routage entre deux LS voisins via le message UPDATE. Ce message UPDATE comporte un certain nombre d'attributs. Un de ces attributs "TRIP route" contient des routes pour joindre des destinations données.
Selon l'invention, un LS annonce des routes incluant des informations de QoS en envoyant un message UPDATE contenant des attributs « TRIP Route » modifiés, tels que décrits dans la section précédente, à ses LS pairs/voisins. A chaque « TRIP Route » sont associés 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 »), mais aussi le chemin des AS transférant effectivement les données au niveau de la couche transfert. Ce chemin des AS est renseigné par un nouvel attribut dénommé « AS_PATH », dont l'identification est détaillée dans la section suivante.
Quand un LS reçoit des routes TRIP dans un message UPDATE d'un LS voisin, il est en mesure de modifier les informations de QoS contenus dans l'attribut « TRIP Route » modifié selon le type de LS duquel il a reçu les routes en question: quand un LS donné reçoit la route d'un autre LS pair situé dans son propre ITAD, ce LS ne modifie pas l'attribut « TRIP Route » ; - quand un LS reçoit la route d'un LS pair situé dans un autre ITAD voisin, alors ce LS peut mettre à jour l'attribut « TRIP Route » comme suit: si l'ITAD voisin utilise le même fournisseur de service de connectivité IP pour évacuer le trafic voix (cette information est contenue dans l'attribut AS_PATH défini dans la section suivante), alors ce LS met à jour les informations contenues dans l'attribut « TRIP Route » modifié en prenant en compte seulement la partie service et non pas les informations de QoS relatives à la partie transport. Cette mise à jour est décrite par la suite, si l'ITAD voisin n'utilise pas le même fournisseur de service de connectivité IP pour évacuer le trafic voix, alors ce LS met à jour les informations contenues dans l'attribut « TRIP Route » modifié en prenant en compte les informations de QoS relatives aux couches service et transport.
Quand un LS est l'origine de l'annonce, il valorise les informations de QoS dans l'attribut « TRIP Route » modifié avec les caractéristiques de QoS incluant les deux couches service et transfert.
La valorisation des informations de QoS relatives à la couche transfert peut être effectuée selon deux approches. Selon une première mise en œuvre, il est possible de ne prendre en compte que les informations locales fournies par le fournisseur de service réseau IP à l'opérateur de téléphonie. Selon une seconde approche, on peut s'appuyer sur les informations de QoS véhiculées par un protocole tel que le q-BGP [QBGP], de la couche transport (dite aussi couche IP).
Ces informations en provenance de la couche IP, par exemple par le biais du protocole q-BGP, peuvent être statiques ou dynamiques :
Statiques : Ces informations de QoS sont dites statiques si leurs valeurs ne varient pas au cours du temps. La valeur de ce type d'informations est renseignée d'une manière statique dans un système. Ces informations sont fournies à l'opérateur de téléphonie IP sous forme d'un contrat de service contenant des clauses de QoS (i.e. « SLA » de l'anglais « Service Level
Agreement » pour « Agrément de Niveau de Service »). Ladite composante de système est statiquement liée audit au moins un système autonome, selon au moins un agrément de niveau de service prédéterminé ; Dans ce cas de figure, un agrément de niveau de service est associé à chaque système autonome. La qualité de service de ce système autonome est donc considérée comme étant constante/statique. L'agrément de niveau de service est négocié de façon statique entre les systèmes autonomes composants le réseau et fourni au domaine de téléphonie IP.
Dynamiques : Les valeurs de ces informations varient au cours du temps. L'opérateur de téléphonie IP peut alors avoir accès aux valeurs dynamiques à l'aide d'une interface mise à sa disposition par le fournisseur de connectivité IP (i.e. gérant TAS dans lequel sont déployés les éléments du domaine de téléphonie) qui a mis en œuvre des mécanismes appropriés tels que des outils de mesure et de surveillance pour juger des performances IP de son propre AS.
La composante de système est dynamiquement liée audit au moins un système autonome par le biais d'une interface de connectivité IP, associant ledit premier serveur de localisation et ledit premier système autonome.
Dans ce cas de figure, la composante système est dynamique et donc varie au cours du temps. Elle est donc accessible aux domaines de téléphonie par le biais d'une interface permettant à un serveur de localisation du domaine de téléphonie de connaître à un instant donné le niveau de qualité de service rendu par le système autonome sur lequel il est basé au travers des plusieurs paramètres de qualité de service.
Les informations de qualité de service manipulées par les serveurs de localisation (en particulier lors de la phase de mise à jour des informations de QoS contenues dans les messages d'annonces de routes reçues ou émises) contiennent quant à elles deux composantes :
La partie service : cette composante renseigne seulement les paramètres de QoS concernant la plateforme de service de téléphonie. Par exemple : le délai moyen requis pour le traitement des appels dans les serveurs de téléphonie est de 5ms, le délai maximum requis pour le traitement des appels dans les serveurs de téléphonie est de 1 Oms.
La partie transport : cette composante concerne les valeurs des paramètres de QoS fournies par le fournisseur de connectivité IP (décrites ci-dessus, et qui peuvent être dynamiques ou statiques). Par exemple: le délai moyen requis pour traverser l'AS est de 50ms, le délai maximum requis pour traverser l'AS est de 100ms.
Ainsi, pour le service de téléphonie, la valeur d'un paramètre de QoS est égal à la somme de la composante service et celle du transfert. Dans l'exemple ci- dessus, le délai moyen requis pour le traitement des appels est de
(5ms+50ms=55ms), le délai maximum requis pour le traitement des appels est de
(10ms+100ms=1 10ms).
Selon l'invention, l'opération de modification des informations de QoS contenues dans les messages TRJP consiste à concaténer les valeurs des paramètres de QoS locales du domaine recevant l'annonce TRIP avec celles déjà contenues dans l'annonce de route (i.e. celles contenues dans le message "UPDATE"). La méthode de concaténation dépend de la nature du paramètre de QoS en question. On peut citer par exemple les paramètres de QoS additifs et les paramètres de QoS multiplicatifs. Pour les paramètres de QoS additifs, le résultat de l'opération de concaténation est l'adition de la valeur locale du paramètre concerné et celle déjà contenue dans le message d'annonce de route reçu de la part d'un LS voisin.
Pour illustrer ce cas de figure, prenons l'exemple du délai moyen. On suppose que deux domaines ITADl et ITAD2 s'échangent des informations de routage TRIP avec des informations QoS. Supposant que la valeur du délai moyen pour traverser l'ITADl est de 15ms, si ITAD2 annonce à ITΛD1 des destinations données avec une valeur du délai moyen égal à 55ms, ITADl peut à son tour annoncer ces destinations à d'autres voisins en valorisant le paramètre de délai moyen à 15ms+55ms=70ms. Pour les paramètres de QoS multiplicatifs, le résultat de l'opération de concaténation est la multiplication de la valeur locale du paramètre concerné et celle déjà contenue dans le message d'annonce de route reçu de la part d'un voisin.
Pour illustrer ce cas de figure, prenons l'exemple d'un paramètre multiplicatif QS l . On suppose que deux domaines ITADl et ÏTAD2 s'échangent des informations de routage TRIP avec QoS. Supposant que la valeur du QSl pour traverser l'ITADl est de VALl, si ITAD2 annonce à ITADl des destinations données avec une valeur du QSl égal à VAL2, ITADl peut à son tour annoncer ces destinations à d'autres voisins en valorisant le paramètre de délai moyen à VAL1 *VAL2).
On présente encore un autre exemple de mise à jour des informations de QoS par un serveur de localisation LS selon l'invention. Supposons qu'un LS local reçoit, de la part d'un LS voisin, une route contenant les informations de QoS suivantes : - Délai moyen = 200ms ;
Délai maximum = 300ms ;
1. si le LS local est dans le même ITAD que le LS voisin qui a annoncé la route, les informations de QoS ne sont pas modifiées ;
2. si le LS est dans un ITAD différents de celui du LS voisin : a. Si les deux ITAD utilisent le même AS, alors seule la composante service des informations de QoS sera prise en compte pour la mise à jour des informations de QoS. Ainsi : i. le délai moyen mis à jour=200ms+5ms=205ms ii. le délai maximum mis àjour=300ms-rl 0ms=310ms b. Si les deux ITAD utilisent des AS différents, alors les deux composantes service et transfert des informations de QoS seront prises en compte pour la mise à jour des informations de QoS. Ainsi : i. le délai moyen mis à jour=200ms+5ms+50=255ms ; ii. le délai maximum mis à jour=300ms+10ms+100=410ms. 5.3 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 servie on introduit un nouvel attribut, dans lequel sont contenues des informations sur les fournisseurs de service de connectivité IP utilisés pour acheminer le trafic voix. Plus clairement, on permet à la couche service d'identifier les AS, ou opérateurs de connectivité IP utilisés pour le trafic voix. Un LS possède alors 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.
5.3.1 Format
Classiquement, on rappelle que le protocole TRIP est mis en œuvre par les LS (serveurs de localisation) qui propagent des routes TRlP, contenant des attributs permettant de qualifier les routes en question. 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 (TRIP) » de janvier 2002) prévoit l'échange d'informations de routage entre deux LS voisins via le message UPDATE, qui comporte un certain nombre d'attributs.
Afin de connaître la liste des fournisseurs de service de connectivité IP utilisés pour acheminer le trafic voix d'un ITAD, on introduit un nouvel attribut nommé AS_PATH. 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 une destination donnée. Il est alors propagé d'un domaine IP à un domaine 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 :
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 pour joindre une destination donnée.
5.3.2 Procédure générale de sélection de route
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 LS voisins et ceux de son propre domaine. Ces annonces sont mises à jour et redistribuées à d'autres voisins si les accords d'interconnexion le permettent.
Ainsi, 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 Ia 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 ASJPATH 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 I1ASJPATH est de type AS^SEQUENCE, 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_PATH vide dans tous les messages UPDATE à envoyer à ses pairs TRIP situés dans son propre ITAD.
5.4 Processus de choix de routes à qualité de service
Dans le but d'améliorer la qualité de service de bout en bout des services de téléphonies, les inventeurs ont constaté qu'il est souhaitable que les processus de sélection d'une route TRIP inter ITAD doit prendre en compte les informations de qualité de service pour orienter la sélection de la route à stocker dans les bases de donnée de routage TRlP. Par conséquent, le processus de sélection de route tel que décrit dans la norme RFC3219 n'est plus approprié puisqu'il ne prend pas en compte ces critères de qualité de service.
On décrit ici deux nouvelles méthodes pour la sélection des routes, basé sur les informations de QoS échangées entre ITAD voisins, selon la procédure précédemment décrite, grâce notamment à l'attribut modifié « TRIP Route ».
On suppose qu'un opérateur de téléphonie IP affecte des priorités à chaque paramètre de QoS annoncé dans les messages TRIP. Par exemple, un opérateur peut affecter au paramètre « Minimum one way delay » (pour « délai de chemin minimum ») une meilleure priorité, et une basse priorité au paramètre « Loss Rate » (pour « taux de pertes ») et ainsi de suite. La valorisation des priorités peut être aussi effectuée par un organisme de standardisation tel que HETF (pour « Internet Engineering Task Force » en anglais) ou PITU (pour « International Télécommunication Union »). Les algorithmes présentés ci-après sont basés sur ce principe d'affectation de priorités pour les paramètres de QoS véhiculés dans les messages TRIP, en particulier dans les attributs "TRlP Route" modifiés conformément à la procédure décrite au paragraphe 5.2 de la présente description. 5.4.1 Algorithme 1 L'algorithme illustré par la figure 7, pour la sélection de routes TRIP, prend en compte les infoπnations de QoS échangées par TRIP et les installe dans la TRIB locale.
Il commence par une première étape 90 d'identification des routes desservant une même destination donnée. U s'en suit une étape 91 d'examen de la caractéristique de performance de
Qualité de Service qui a la plus haute priorité. Dans cette même étape 91, les routes qui optimisent cette caractéristique de performance de Qualité de Service sont identifiées.
Deux cas de figures sont alors pris en compte. Si une seule route est renvoyée (i), l'algorithme effectue une étape 93 de stockage de cette route dans la TRIB locale. Si plus d'une route est renvoyée (ii), une étape 92 « exclut » la caractéristique de performance de Qualité de Service qui est utilisée à l'étape 91 de la liste des caractéristiques de performances de Qualité de Service. a) Si, à la suite de cette étape 92 « d'exclusion », il n'y a aucune caractéristique de performance de Qualité de Service restante, le procédé classique de sélection de route TRIP est réalisé, dans une étape 94, si plus d'une route a été identifiée lors de l'étape 90; b) Sinon, l'algorithme réitère l'étape 91. 5.4.2 Algorithme 2
Cependant, dans un autre mode de réalisation de l'invention, il est possible d'introduire un niveau hiérarchique pour contrôler les informations de QoS échangées par TRlP entre deux voisins. L'algorithme précédent peut alors être modifié. Le niveau hiérarchique supplémentaire introduit peut correspondre alors à la définition de deux types de paramètres de QoS :
« Mandatory » (obligatoire) correspond à l'ensemble de paramètres de QoS qui doivent être renseignés par un LS voisin dans ses messages UPDATE. Si une annonce TRlP ne contient pas un paramètre de QoS de ce type, cette annonce est supprimée ;
« Optionnal » (Optionnel) est une catégorie dans laquelle on groupe les informations de QoS optionnelles qui peuvent être renseignées par un LS voisin dans ses messages UPDATE. Si une annonce TRlP ne contient pas un paramètre de QoS de ce type, cette annonce n'est pas supprimée.
Ce niveau de contrôle a pour but d'assurer une consistance quant aux informations de QoS échangées entre les opérateurs de téléphonie IP, c'est-à-dire entre ITAD. Cependant le caractère obligatoire ou optionnel des paramètres peut tout à fait être introduit en dehors de toute hiérarchisation des paramètres. En relation avec la figure 8, l'invention propose un nouvel algorithme prenant en compte ce niveau hiérarchique pour une sélection de route optimale en termes de Qualité de Service de bout en bout.
Il comprend tout d'abord une étape 100 d'identification des routes qui servent une même destination donnée. Si le nombre de routes restantes est non nul, il s'en suit une étape 1 10 de vérification, pour chaque route, si toutes les caractéristiques « mandatory » de performances de Qualité de Service sont présentes/valorisées.
Si oui, la route en cours de vérification est ajoutée à la liste des routes restantes dans une étape 1 1 10. Si non, cette roule est écartée (étape 1 120). Les routes restantes sont ensuite examinées dans une étape 120.
Si le nombre de routes restantes est non nul, une étape 1200 examine la caractéristique de performance de qualité de service qui a la priorité la plus haute, et renvoie les routes qui optimisent cette caractéristique de performance de Qualité de Service : a) si une seule route est renvoyée, une étape 1210 stocke cette route dans la TRlB locale ; b) si plus d'une route est renvoyée, une étape 1220 exclut la caractéristique de performance de Qualité de Service qui a été utilisée à l'étape 1200 de la liste des caractéristiques de performances de Qualité de Service.
A la suite de cette étape 1220, s'il ne reste aucune caractéristique de performance de Qualité de Service, le procédé classique de sélection de route TRIP est mis en œuvre (étape 130), si plus d'une route à été renvoyée, lors de l'étape 100.
En revanche, s'il reste une caractéristique de performance de Qualité de Service, l'étape 1200 est réitérée.
A la suite de l'étape 120, si le nombre de routes restantes est nul, l'algorithme exécute le procédé classique de sélection de route TRIP à l'étape 130, sous la condition que plus d'une route ait été retournée lors de l'étape 100.
En conclusion, ces deux procédés sont avantageux à un opérateur de téléphonie IP souhaitant déployer un mécanisme d'échange d'informations de QoS avec ses opérateurs voisins. Ces algorithmes sont invoqués pour choisir les routes TRIP à installer dans les tables de routages locales. Grâce à ceux-ci, les opérateurs de téléphonie sont en mesure de choisir des routes optimales et dont la qualité de service est meilleure. Ces algorithmes peuvent, dans un mode de réalisation particulier, être mises en œuvre une optimisation des coûts des appels. ANNEXE RFC3219
Longueur (« Length ») : Correspond à la longueur du champ « Address », en octets ;
Adresse (« Address ») : Correspond à une adresse (préfixe) du type de famille donné identifié par le champ Famille d'adresse (« Address Family »). La longueur en octets de l'adresse est variable et est déterminée par la longueur de champ de la route.

Claims

REVENDICATIONS
1. Procédé de propagation d'au moins une route d'acheminement d'au moins un flux numérique entre un premier serveur de localisation d'un premier domaine de téléphonie IP et un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un premier système autonome et ledit deuxième serveur de localisation appartenant à un deuxième système autonome, ledit procédé comprenant une étape d'envoi de messages de mise à jour de routes d'acheminement de flux numériques audit deuxième serveur de localisation, caractérisé en ce que lesdits messages de mise à jour contiennent des informations de gestion de la qualité de service, et en ce que lesdites informations de gestion de la qualité de service sont mises à jour par ledit premier serveur avant propagation vers ledit deuxième serveur en se basant sur au moins une caractéristique de qualité de service dudit premier domaine de téléphonie et/ou dudit premier système autonome.
2. Procédé de propagation d'au moins une route d'acheminement selon la revendication 1, caractérisé en ce que lesdites informations de gestion de qualité de service comprennent au moins une des informations suivantes : une information composante de qualité de service liée à au moins un système autonome, dite composante de système ; une information composante de qualité de service liée à au moins un domaine de téléphonie IP, dite composante de domaine ;
3. Procédé de propagation selon la revendication 2 caractérisé en ce que lorsque ledit premier domaine de téléphonie IP et ledit deuxième domaine de téléphonie IP sont identiques, ladite mise à jour ne modifie pas les informations de gestion de la qualité de service.
4. Procédé de propagation, selon la revendication 2, caractérisé en ce que lorsque ledit premier domaine de téléphonie IP et ledit deuxième domaine de téléphonie IP sont distincts et que ledit premier système autonome et ledit deuxième système autonome sont identiques, ladite mise à jour ne prend en compte que ladite au moins une composante de domaine.
5. Procédé de propagation, selon la revendication 2, caractérisé en ce que lorsque ledit premier domaine de téléphonie IP et ledit deuxième domaine de téléphonie IP sont distincts et que ledit premier système autonome et ledit deuxième système autonome sont distincts, ladite adaptation prend en compte ladite au moins une composante de domaine et ladite au moins une composante de système.
6. Procédé de propagation selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une étape préalable de négociation d'une capacité de gestion de qualité de service, selon au moins un paramètre prédéterminé, entre ledit premier et ledit deuxième serveurs de localisation de telle sorte que les desdits serveurs de localisation échangent des messages de mise à jour contenant des informations de qualité de service.
7. Procédé de propagation selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend une étape de sélection d'au moins une route à propager en fonction desdites informations de gestion de la qualité de service.
8. Procédé de propagation selon la revendication 7, caractérisé en ce qu'au moins un desdits paramètres de qualité de service est un paramètre de qualité de service obligatoire, et en ce que ladite étape de sélection tient compte dudit au moins un paramètre de qualité de service obligatoire.
9. Procédé de propagation selon l'une quelconque des revendications 7 et 8, caractérisé en ce que ledit au moins un paramètre de qualité de service présente un niveau de hiérarchie, et en ce que ladite étape de sélection tient compte dudit niveau de hiérarchie.
10. Serveur de localisation d'un premier domaine de téléphonie IP, apte à propager au moins une route d'acheminement d'au moins un flux numérique entre vers un deuxième serveur de localisation d'un deuxième domaine de téléphonie IP, ledit premier serveur de localisation appartenant à un premier système autonome et ledit deuxième serveur de localisation appartenant à un deuxième système autonome, ledit premier serveur de localisation comprenant des moyens d'envoi de messages de mise à jour de routes d'acheminement de flux numériques audit deuxième serveur de localisation, caractérisé en ce que lesdits messages de mise à jour contiennent des infoπnations de gestion de la qualité de service, et en ce que lesdites informations de gestion de la qualité de service sont mises à jour par ledit premier serveur avant propagation vers ledit deuxième serveur en se basant sur au moins une caractéristique dudit premier domaine de téléphonie et/ou dudit premier système autonome.
11. 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 à 9, lorsqu'il est exécuté sur un ordinateur.
EP07731926A 2006-04-21 2007-04-20 Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d'ordinateur correspondants Withdrawn EP2052505A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0603623 2006-04-21
PCT/FR2007/051151 WO2007122355A1 (fr) 2006-04-21 2007-04-20 Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
EP2052505A1 true EP2052505A1 (fr) 2009-04-29

Family

ID=37684109

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07731926A Withdrawn EP2052505A1 (fr) 2006-04-21 2007-04-20 Procede de prise en compte de la qualite de service entre domaines de telephonie ip distincts, serveur de localisation et programme d'ordinateur correspondants

Country Status (3)

Country Link
US (1) US8761155B2 (fr)
EP (1) EP2052505A1 (fr)
WO (1) WO2007122355A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US7990892B2 (en) * 2006-04-21 2011-08-02 France Telecom Method of selecting a telephony route within an IP telephony domain, and corresponding apparatus and computer program
KR102017408B1 (ko) * 2015-03-02 2019-09-02 콘비다 와이어리스, 엘엘씨 서비스 계층 능력을 사용한 네트워크 및 애플리케이션 관리
JP7230729B2 (ja) * 2019-08-01 2023-03-01 日本電信電話株式会社 経路制御装置、経路制御方法、及びプログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6487283B2 (en) * 1998-08-04 2002-11-26 Transnexus, Inc. Pricing center for internet protocol routed transactions
US6584093B1 (en) * 1998-08-25 2003-06-24 Cisco Technology, Inc. Method and apparatus for automatic inter-domain routing of calls
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
US7133923B2 (en) * 2000-12-11 2006-11-07 Acme Packet, Inc. System and method for assisting in controlling real-time transport protocol flow through multiple networks via screening
CN100358291C (zh) * 2004-09-08 2007-12-26 华为技术有限公司 下一代网络中动态协商服务质量的系统及其实现方法
US7409482B2 (en) * 2004-10-26 2008-08-05 Lenovo (Singapore) Pte, Ltd. Computer and method for on-demand network access control

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2007122355A1 *

Also Published As

Publication number Publication date
WO2007122355A1 (fr) 2007-11-01
US8761155B2 (en) 2014-06-24
US20090175266A1 (en) 2009-07-09

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
US8218536B2 (en) Routing protocol with packet network attributes for improved route selection
EP2294798B1 (fr) Procede de routage d&#39;un paquet de donnees dans un reseau et dispositif associe
EP1479203B1 (fr) Correlation des requetes en qualite de service
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
EP2109991B1 (fr) Optimisation de l&#39;acheminement de communications entre une pluralite de domaines de telephonie
EP2057795B1 (fr) Procédé de propagation de routes de téléphonie ip multiples, serveur de localisation et programme d&#39;ordinateur correspondants
EP1432184B1 (fr) Dispositif de détermination de chemins de communication dans un réseau de communications à commutation d&#39;étiquettes, en présence d&#39;attributs de sélection
EP2449745B1 (fr) Procédé de sélection d&#39;une ressource réseau
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
EP4409864A1 (fr) Procédé de controle d&#39;un accès à un service applicatif mis en oeuvre dans un réseau de télécommunications, procédé de traitement d&#39;un message de controle d&#39;un accès audit service applicatif, dispositifs, équipement de controle, équipement client, système et programmes d&#39;ordinateur correspondants
EP1575215A1 (fr) Contrôleur de bande passante, réseau et procédé de gestion de sous-réseau IP
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
FR3153206A1 (fr) Procédés, dispositifs et système de contrôle d’une communication dans un réseau
WO2004071029A1 (fr) Signalisation dans les reseaux actifs pilotes
WO2025132510A1 (fr) Coordination d&#39;identifiant d&#39;acheminement symétrique pour l&#39;établissement d&#39;un tunnel de communication
WO2025132512A1 (fr) Coordination d&#39;identifiant d&#39;acheminement symétrique pour l&#39;établissement d&#39;un tunnel de communication
EP1762051A1 (fr) Procede de gestion d&#39;une interconnexion entre reseaux de telecommunication et dispositif mettant en oeuvre ce procede

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

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

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 12/70 20130101AFI20170110BHEP

INTG Intention to grant announced

Effective date: 20170206

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