EP2052505A1 - Method for taking into account the quality of service between distinct ip telephony domains, corresponding locating server and computer programme - Google Patents

Method for taking into account the quality of service between distinct ip telephony domains, corresponding locating server and computer programme

Info

Publication number
EP2052505A1
EP2052505A1 EP20070731926 EP07731926A EP2052505A1 EP 2052505 A1 EP2052505 A1 EP 2052505A1 EP 20070731926 EP20070731926 EP 20070731926 EP 07731926 A EP07731926 A EP 07731926A EP 2052505 A1 EP2052505 A1 EP 2052505A1
Authority
EP
Grant status
Application
Patent type
Prior art keywords
service
quality
qos
server
ip telephony
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
EP20070731926
Other languages
German (de)
French (fr)
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
Orange 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

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network-specific arrangements or communication protocols supporting networked applications
    • H04L67/32Network-specific arrangements or communication protocols supporting networked applications for scheduling or organising the servicing of application requests, e.g. requests for application data transmissions involving the analysis and optimisation of the required network resources
    • H04L67/322Network-specific arrangements or communication protocols supporting networked applications for scheduling or organising the servicing of application requests, e.g. requests for application data transmissions involving the analysis and optimisation of the required network resources whereby quality of service [QoS] or priority requirements are taken into account
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/04Interdomain routing, e.g. hierarchical routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/30Special provisions for routing multiclass traffic
    • H04L45/302Route determination based on requested QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/30Special provisions for routing multiclass traffic
    • H04L45/306Route determination based on the nature of the carried application
    • H04L45/3065Route determination based on the nature of the carried application for real time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/10Signalling, control or architecture
    • H04L65/1066Session control
    • H04L65/1069Setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements or protocols for real-time communications
    • H04L65/80QoS aspects

Abstract

The invention concerns a method for propagating at least one path for routing at least one digital stream between a first locating server of a first IP telephony domain and a second locating server of a second IP telephony domain, said first locating server belonging to a first autonomous system, and said second locating server belonging to a second autonomous system, said method including a step of sending messages for updating paths for routing digital streams to said second locating server. According to the invention, said updating messages contain data for managing quality of service and said quality of service management data are updated by the first server prior to propagating to the second server based on at least one quality of service characteristic of said first telephony domain and/or of said first autonomous system.

Description

The process of recognition of the quality of service between different areas of IP telephony, location server and corresponding computer program.

1 FIELD OF THE INVENTION The present invention relates to the field of telephony on Internet type networks via IP-based networks (from the English "Internet Protocol" for "Internet Protocol"). Telephony means equally conventional telephony, video telephony services or synchronous digital data transfer services. More specifically, the present invention falls within the framework of the integration of QoS parameters allowing telephony domains management entities to route calls by offering an optimal quality of service.

In particular, the invention relates to a method of managing the quality of service between the telephony domains management entities on networks using, for example, a communication mechanism based on IP (from the English " Internet Protocol "for" Internet Protocol ").

The IP network is the backbone adopted by operators to pool their diverse service offerings including IP telephony Ia commonly referred to by the acronym VoIP (standing for "Voice over IP" for "Voice over IP") or, more generally grouped under themed conversational services.

The deployment of these applications of voice and video in real time to all-IP and migration of dial-up, traditionally appointed by the RTC, forcing operators to provide global coverage worldwide, of these services. This is not only down to ensure points of presence around the globe but to offer customers the ability to attach any destination (ie the customers of other operators). This comprehensive coverage is achieved through the establishment of interconnection agreements with other third party service providers in order to expand the scope of a service outside the administrative borders of a single service provider.

In this dynamic thread, it is expected that cooperation between VoIP / IP telephony service providers ( "Telephony over IP" for "IP telephony") will intensify in the short and medium term. This increase should allow the evacuation traffic related to the voice endpoints are outside IP telephony domains (also called "ITAD" English "IP Telephony Administrative Domain") operators. This cooperation between suppliers are even more strategic than conventional bilateral type agreements do not ensure global coverage required by operators.

In addition, the phone offers deployed over an IP network must meet quality requirements such as high availability and high fault tolerance. The service availability constraint is not only about the transfer layer (network layer / OSI transport) but also the service layer.

In the remainder of this document indifferently use the terms of

"Quality of Service" or "QoS" that designate the same concept. Reference is also made to the following terms: - LS ( "Location Server" for "Location Server") is an entity of a telephony domain (ITAD), which manages the locations of customers and routes a ITAD local. This equipment can interface with a neighboring LS to learn Ia location of customers managed by other ITAD; AS ( "Autonomous System" for "Autonomous System"): It is a set of IP resources managed by a single administrative entity, also called "IP connectivity provider." As part of the routing protocol BGP inter-domain (from the English "Border Gateway Protocol" [RFCL 771]), each AS is identified by a unique identifier. AS This is also called "IP transfer domain". 2 SOLUTIONS OF THE PRIOR ART

2.1 BACKGROUND

In telephony "classic" (world PSTN, PSTN) telephone operators establish bilateral agreements to extend the global coverage of the telephone service. The level of coverage achieved mainly on the number of established agreements. One can very schematically consider two categories of telecommunications operators exist: local and / or national and global operators operators. The world's largest carriers establish a large number of agreements and can reach most existing destinations. Local operators establish only a limited number of agreements which only one or two with major operators. Thus, a historical national operator of a developing country will establish agreements with other national operators and one or two agreements with global operators to evacuate communications to the rest of the world.

Currently, most operators are migrating their networks to PSTN solutions and infrastructures based on the "IP" network. To support the deployment of service "VoIP", I 1 IETF ( "Internet Engineering Task Force" for "Internet Development Group") has worn many standardization work. Several protocols have been specified among which include SIP ( "Session Initiation Protocol" for "Session Initiation Protocol"). SDP ( "Session Description Protocol" to "Session Description Protocol"), RTP ( "Real-time Transfer Protocol" for "transfer protocol in real time"), PSTN ( "Real-Time Transfer Control Protocol" to "Protocol real-time transfer of control "), MGCP (" multimedia Gateway control Protocol "to" multimedia backbone control Protocol "), SAP (" session announcement Protocol "to" Memorandum of session announcement ") and TRJP (telephony Routing over IP [RFC3219] for "IP telephony routing"). These protocols serve different needs and integrate in particular signaling and call control, exchange of media streams and control and the exchange of call routing information.

TRlF allows ITAD interconnected to exchange all the destinations they can reach and also facilitates the selection of "Gateway" ( "Highway" or "backbone") most appropriate to evacuate IP telephony traffic to the PSTN. The TRIP protocol is implemented by LS ( "Location Servers" for "Location Servers") that spread TRJP routes containing attributes that describe the routes in question. The use of this particular protocol is independent of the type of the signaling protocol deployed for the effective establishment of calls. The TRIP protocol can be used with SIP, H.323 or other signaling protocol. Each LS maintains a local routing database called TRIB ( "Telephony Routing Information Database" to "basic telephony routing information data"). This basic routing is fed through advertisements received from neighboring LS (from another telephony domain, for example). The operation of the TRIP protocol is similar to that Protocol BGP ( "Border Gateway Protocol"). The ads between LS neighbors are made in the form of route update messages, also named "UPDATE" message. These messages are defined by the TRIP protocol and are exchanged between LS infoπner to a nearby area of ​​available roads.

Is described in relation to Figure 1, activation of the TRIP protocol between different ITAD (for simplicity, it also uses the term "domain" to denote an ITAD) ITAD each being administered by a single telephone operator . These operators each have one or more LS. Each LS maintains a database of routing it feeds with advertisements received from its neighbors (located in other areas) and LS its own domain. These ads are updated and redistributed to other neighbors if the agreements allow.

Thus FITAD4 14, for example, updates the advertisements received from FITAD5 15 and re-spreads ITAD3 13. It should be noted that an ITAD is not necessarily deployed on a single "IP domain transfer" also called an AS.

Routing point of view, an LS addresses three types of roads: external routes (Routes External) received from LS located in ITAD neighbors; internal routes (Routes Internai) received from LS located in the same

ITAD; local roads (Local roads), configured locally in each LS to be injected into TRIP processes. This is done either through static configuration or redistribution of information from other routing protocols.

Thus, four types of "TRlB" are managed by an LS as shown in Figure 2. These tables exist for the same LS, relations between these tables are illustrated in connection with Figure 2. - "Adj -TRIBs-In "22: stores routing information conveyed by update messages. This routing information, also called "roads" are the inputs of a 21 roads selection process (from the English "Decision Process"). A given LS maintains a table "Adj- TRlB-In" 22 (for "adjacent TRIB in" which stores the set of routes of advertisements received from an adjacent LS) by neighboring LS;

"Ext-TRIB" 24: Only one table "Ext-TRIB" ( "external TRIB") is maintained by LS. This table contains the result of a route selection process applied to external routes 25 ( "Adj-TRIBs-IN") and Local 26 ( "Local Roads"). Fart previous techniques do not allow to choose a single route by destination;

"Loc-TRIB" 20 ( "Local TRIB"): This table contains the local roads resulting from the application of local routing policies for each LS; "WO-TRIBs-Out" 23 ( "Adjacent TRIB out"): These are the roads that Ie local LS will announce its peers. In the transfer layer (layer responsible for the actual transfer of calls), you can use the q-BGP ( "QoS-Enhanced Border Gateway Protocol" for "Routing Protocol interdomain Augmented QoS") to find treatment QoS will be reserved for voice flow. In the present techniques of the prior art, there is no quality management mechanism service between IP telephony operators.

2.2 Disadvantages of the prior art

A disadvantage of this technique of the prior art is that the problem of QoS was not considered in the service level by existing approaches. The phone deals are based on the transfer layer to ensure the processing of QoS required by digital streams (audio and / or video) to transfer.

However there is no means for correlating (dynamically) the two layers (service, for ITAD via TRIP protocol for example and transfer to the AS through the BGP, for example). A correlation can be established, but it requires configuration of static routes. Indeed, the TRIP protocol does not define attribute that allows easy correlation with the protocol "q-BGP" and QoS information as it travels between different edge routers.

Another disadvantage of this technique of the prior art is that the LS does not have dynamic and credible ways to judge the QoS associated with a given road. Therefore, the LS can choose paths that offer not comply with the QoS expectations of customers and end-optimal communications.

3 SUMMARY OF THE INVENTION

The solution proposed by the invention overcomes these drawbacks of the prior art, through a propagation process of 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 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 method comprising a step of sending by said first server of location update messages conveying routes digital stream at said second location server.

According to the invention, the method of propagation is characterized in that said update messages contain service quality management of information and in that said service quality management information is updated by said first server before propagation to said second server based on at least one quality of service feature of said first field of telephony and / or said first autonomous system.

Thus, the invention is based on an approach entirely new propagation of routing routes in IP telephony domains, allowing these areas to receive information about the quality of implementation services during the delivery of digital streams. These QoS information is contained in the messages to update routing road that are exchanged between location servers that make up part of the areas of IP telephony. It is not necessary to modify existing hardware architectures to reflect the quality of service as an additional criterion for selection of cross-domain routes.

According to an original feature of the invention, said quality of service management information includes at least one of the following information: information QoS component linked to at least one autonomous system, said system component; information QoS component linked to at least one IP telephony domain, said domain component: The data are split into two components. The exchanged QoS information may well reflect the telephony domains and autonomous systems being responsible for the effective transfer of IP packets, ensuring at the same time consistency between the "service" layer of the telephony domain and the "transfer layer "managed eg by knots component standalone systems.

In a particular aspect of the invention, when said first IP telephony domain and said second IP telephony domain are identical, said update does not change the quality of service management information.

Thus, when transferring the route update messages between location servers, the location server that processes a message to spread can update the QoS information contained in this message. If this message is spread to a location server being located in the same area, then the QoS information is not updated. Indeed, when two location servers belonging to the same area, the quality of service rendered by an area can be regarded as being the same in each of the field location server.

According to a particular characteristic of the invention, when said first IP telephony domain and said second IP telephony domain are distinct and that said first autonomous system and said second autonomous system are identical, said updating takes into account that the at least one field component.

Indeed, when the autonomous systems borrowed to join the different telephony domains which belong to two location servers are identical, the quality of service offered to the transfer level does not change. Thus, a route that takes two different telephony domains, but only one standalone system will suffer the quality of service related to telephony domains, but one rendered during the transfer of IP packets is the one made by the autonomous system. The update thus takes account of the domain component, which is the only change in this case.

In a particular aspect of the invention, when said first IP telephony domain and said second IP telephony domain are distinct and that said first autonomous system and said second autonomous system are separate, said updating takes into account said at least one field component and said at least one system component.

Thus, in the case of a road through several telephony domains and several stand-alone systems, the two components of service quality management information is used to update the quality of service associated with the routing road considered.

According to a particular characteristic of the invention, said method comprises a prior step of negotiating a QoS management capacity, according to at least one predetermined parameter between said first and said second location servers so that the servers of said location exchange update messages with QoS information ..

In order to make possible the exchange of QoS information between location servers and at the same time to make this information available to the telephony domains, location servers negotiate before any exchange of road and respective capabilities taking into account the quality of service. Thus, it is ensured that the location server exchange service quality information that they are mutually adapted to take into account.

According to an original feature of the invention said method comprises a step of selecting at least one route to propagate in accordance with said quality of service management information.

Thus, a location server may choose a route to spread to another location server based QoS management information available for a given destination. The location server and selects routes that match the quality expectations for the transfer of digital streams from the standpoint of phone service.

According to a particular feature of the invention said at least one quality of service parameter is a required quality of service parameter, and said selection step takes account of said at least one required quality of service parameter.

Thus, when these parameters are required, selecting the road to spread will reflect the presence and value of the required parameters.

According to a particular aspect of the invention, said at least one service quality parameter comprises a hierarchy level, and said selection step takes account of said hierarchy level.

Together with their composite nature, these QoS parameters also include hierarchy levels. These levels are independent of mandatory and / or optional parameters. They allow you to prioritize the parameters when selecting the route to spread. Thus some settings can be considered before others when selecting the road to settle in the local routing tables and consequently that to spread to other peers.

The invention also relates to a location server of a first IP telephony domain, capable of propagating at least one conveying route 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 said stream of digital delivery routes second location server, wherein said update messages contain QoS management information, and in that said service quality management information is updated by said first server before propagation to said second server based on at least one characteristic of said first field of telephony and / or udit first autonomous system.

Thus, such a location server allows to convey QoS management information between IP telephony domains.

More generally, such a location server comprises means for implementing the steps of the method of propagation of at least one route of delivery.

In another embodiment, the invention also relates to a computer program product downloadable from a communications network and / or stored on a computer readable medium and / or executable by a microprocessor.

According to the invention, in at least one embodiment, such a computer program product comprises program code instructions for the execution of the propagation method at least one conveying route as described above. 4 LIST OF FIGURES

Other features and advantages of the invention will become apparent from reading the following description of a preferred embodiment given as a simple illustrative and not restrictive, and the appended drawings, in which Figure 1 , already discussed, shows an example of architecture of telephony domains (ITAD); 2 illustrates the structure of the routing databases (TRIB) used by the location server (LS) routing the call in the telephony domains (ITAD) shown in Figure 1; Figure 3 illustrates the format of a "Capability" attribute; 4 illustrates the field format "Capability Value" attribute of the new "Road QoS Capability" specific to the invention; - Figure 5 shows the conventional format of the attribute "TRIP Route"; Figure 6 shows the attribute format "TRIP Route" modified according

T invention; Figure 7 is a flow chart shows a route selection algorithm according to a first embodiment; - Figure 8 is a flowchart illustrating a route selection algorithm taking according to a second embodiment. 5 DETAILED DESCRIPTION OF THE INVENTION

For clarity, we present below an embodiment of the invention implementing the TRIP protocol at the service layer. However, it is clear that the invention is not limited to this particular protocol, but can also be applied to any new route exchange protocol between IP telephony domains.

5.1 General

The present invention includes two major aspects. First, it presents a new information technology operating in the service layer with the quality of service effective transfer level. Then she introduced two new processes and optimal route selection for an optimal quality of service.

In other words, it manages the quality of service of telephony routing protocol, eg "TRJP" and offers features for selecting roads to service quality.

The invention therefore provides an optimization technique of the inter-domain QoS based on QoS information exchanged between telephony domains. We'll talk later of QoS information to indicate this information on the quality of effective services at the data transfer layer.

With this information, the LS can select the best path that provides the desired QoS to establish a data communication.

To avoid closing TRIP sessions due to exchange attributes or non-compliant messages to RFC TRIP, the RFC3219 standard (described in the document RFC3219 Rosenberg et al. "Telephony Routing over IP (TRIP ) "of January 2002) suggested exchanging during the opening of the session TRIP" capacity "(" capabilities ") of each LS, and will exchange the attributes supported by the two communicating peer LS therebetween. Thus each LS informs its neighbor of the options that it supports, and the latter must never send messages that can not be interpreted correctly by his neighbor. Otherwise, the TRIP session is closed.

In the context of this invention, we introduce a new attribute "Capability" TRIP denoted "QoS route capability" and a new format of the attri goal "TRIP Route".

The new attribute "QoS Route Capability" is intended to inform the various LS support roads containing QoS information for instance TRIP when opening the TRIP session. Without this negotiation phase, TRIP session may be closed if a peer LS sends "TRIP Route" not conform to the format defined in RFC3219 standard. Once the negotiation phase of "Capabilities" successful, two LS peers can exchange update messages containing attributes "TRIP Route" modified. Therefore, the TRIP protocol will support roads including QoS information. The attribute "TRIP Route" altered states meanwhile QoS values ​​associated with the road in question. These values ​​are used to inform the neighboring LS, and thus spread the quality of service associated with a given road. Note that, in the terminology TRIP, a road denotes a destination address list (each address is defined by a AFl (Address Family Indicator) and a prefix) associated with an application protocol such as SIP or H.323. Each route has a set of attributes such as "NextHopServer", "AdvertisementPath" and "RoutedPath". including the significance of these attributes is detailed in the document RFC3219 respectively in paragraphs 5.3, 5.4. 5.5. These attributes are used to guide Ie choice of route to install in the TRIB. 5.2 Description of new attributes QoS

To select a path ITAD that offers better guarantees QoS, the LS must have access to QoS information. Two modes are possible: either the QoS information is exchanged in TRJP or consult the LS routing tables q-BGP. We present in this embodiment, a QoS information exchange related to TRIP protocol.

5.2.1 "QoS Route Capability"

According to the conventional TRIP procedure, the new "Capability" attribute of the invention, that is to say "QoS Route Capability" is exchanged in starting 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. Note that this attribute is optional and is not not necessarily supported by all TRIP implementations. It contains three fields 31, 32 and 33: a first field 31 'Capability Code ", a length of two bytes contains a code identifying the" capability "; a second field 32 'Capability Length ", a length of two bytes long, contains the length of the" Capability "; - Finally, a third field 33 'Capability Value ", whose size is variable contains the value of" capablity ".

To avoid mistakes during exchanges update messages containing "TRIP Route" attribute modified, avoid closing TRIP sessions and indicate a peer LS given the support roads with QoS information, we introduced a new "Capability "denoted" QoS Route Capability "which

"Capability Code" is 4.

Field format "Capability Value" 33 of the attribute "Capability Information" specific "QoS Route Capability" is shown in Figure 4.

It contains a series of fields 41, 43 "Address Family" (address family) and fields 42, 44 "Application Protocol" (Application Protocol). each of these two fields having a size of two bytes. A peer LS can tell its neighbors types supported and addresses that will be used in the valuation of the fields TRIP routes. One or more pairs ( "Address Family", "Application Protocol") may be entered. In relation to Figure 4, a first pair 420 is composed of fields 41 and 42 and a second pair 430 is composed of fields 43 and 44 for example.

The meanings of the fields 41, 42, 43, 44 "Address Family" and "Application Protocol" are the same as described in section 5.1.1 of RFC3219, and listed in Annex, Annex integral part of this description .

5-2.2 The attribute "TRIP Route" modified

The current specification (RFC3219) of the TRIP protocol does not allow to advertise QoS information. The format of the attribute "TRIP Route" defined by RFC3219 is illustrated in Figure 5. It contains four fields 51, 52, 53 and 54, respectively corresponding to

"Address Family", "Application Protocol", "Length" and then "Address". The first three fields 51, 52 and 53 have a size of two bytes, while the last field 54 is of variable size.

According to the invention, allowing to announce the TRIP routes including QoS information, the attribute "TRIP Route" is amended as shown in Figure 6.

It contains several fields, numbered 61 to 74, and whose appointment and size are as follows: the field 61 "QoS information length" of a length of a byte; - the field 62 "QoS Information Code" of a length of four bits (half a byte); the field 63 'QoS Sub-code information "with a length of four bits; the field 64 'QoS information Value "with a length of two bytes; Fields 62, 63 and 64 are repeated according to a number of quality of service parameters supported by the road; 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 a variable length.

The fields "Address Family", "Application Protocol", "Length" and "Address" are defined in Section 5.1.1.1 of the RFC3219 standard, and reported in the appendix to this description. The new fields according to the invention have the following meanings: the "QoS information length" field indicates the number of QoS information codes (ie the number of QoS parameters) sent by an LS in an update message to its neighbors LS (peers); the "QoS Information Code" indicates the type of information in the informed QoS "QoS information value" field. This field can take the following values:

(0) "Reserved"

(1) "Packet rate"

(2) "One-way delay metric" - (3) "Inter-packet delay variation" the "QoS information sub-code" field indicates the subtype informed QoS information in the "QoS information value" field . This field can take the following values: (O) "None" - (1) "Reserved spleen"

(2) "Available spleen"

(3) "loss rate"

(4) "Minimum one-way delay"

(5) "One way delay Maximum" - (6) "Average one-way delay" the "QoS information value" field shows the value of the QoS information. The unity of this field depends on the type of the code of QoS information.

5.2.3 Procedure Recall that the standard version of the TRIP protocol provides for the exchange of routing information between two neighboring LS via the update message. This update message includes a number of attributes. One of these attributes "TRIP Route" contains road to join data destinations.

According to the invention, an LS ad roads including QoS information by sending an update message containing "TRIP Route" attribute modified as described in the previous section, its peer LS / neighbors. Each "TRIP Route" associated specific road attributes such as path ITAD (both attributes that inform such information are

"AdvertisementPath" and "RoutedPath"), the next jump (informed by the attribute "NextHopServer"), but also the way the AS actually transferring data at the transfer layer. This path AS is entered by a new attribute called "AS_PATH" whose identification is detailed in the next section.

When an LS receives TRIP routes in an update message from a neighboring LS, it is able to modify the information contained in the QoS attribute "TRIP Route" changed depending on the 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, the LS does not change the "TRIP route" attribute; - When an LS receives the route of a peer LS in another neighboring ITAD, then this LS can update the attribute "TRIP Route" as follows: if the neighboring ITAD uses the same IP connectivity service provider to evacuate voice traffic (this information is contained in the AS_PATH attribute defined in the next section), then this LS updates the information contained in the attribute "TRIP Route" modified taking into account only part of the Service and not no QoS information about the transportation 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 in the attribute "TRIP Route" modified taking into account the QoS information to the layers service and transportation.

When an LS is the origin of the ad, it enhances the QoS information in the attribute "TRIP Route" modified with QoS characteristics including both service and transfer layers.

The valuation of QoS information relating to the transfer layer can be performed using two approaches. In a first implementation, it is possible to take into account that the local information provided by the IP network service provider to service provider. In a second approach, we can rely on QoS information carried by a protocol such as the q-BGP [QBGP], the transport layer (also called IP layer).

This information from the IP layer, for example through the q-BGP can be static or dynamic:

Static: These QoS information are called static if their values ​​do not vary over time. The value of this type of information is populated in a static way in a system. This information is provided to the IP telephony operator in the form of a service contract containing QoS clauses (ie "SLA" English "Service Level

Agreement "for" Service Level Approval "). Said system component is statically linked to said at least one autonomous system, according to at least one predetermined service level authorization; In this case, a service level of approval is associated with each autonomous system. The quality of this autonomous system service is considered constant / static. The accreditation service level is negotiated statically between autonomous systems network components and provided to the IP telephony domain.

Dynamic: The values ​​of this information varies over time. The IP telephony operator can then have access to dynamic values ​​using an interface made available by the IP connectivity provider (ie CAS manager in which are deployed elements of the telephony domain) that has implement appropriate mechanisms such as measurement and monitoring tools to assess IP performance of its own aS.

The system component is dynamically linked to said at least one autonomous system via an IP connectivity interface, combining said first location server and said first autonomous system.

In this case, the system component is dynamic and varies over time. It is available on telephony domains through an interface to a location server in the telephony domain to know at a given service quality level made by the autonomous system on which it is based through more service quality parameters.

The service quality information manipulated by location servers (especially when the update phase QoS information in the roads of ad messages received or sent) contain for their two components:

The operating part: This component information only QoS parameters for the telephony service platform. For example: the average time required to process calls in telephony servers is 5ms, the maximum time required for processing calls in telephony servers is 1 Oms.

The transport component: This component concerns the QoS parameter values ​​provided by the IP connectivity provider (as described above, and can be static or dynamic). For example: the average time required to cross the AS is 50ms, the maximum time required to cross the AS is 100ms.

Thus, for the telephony service, the value of a QoS parameter is equal to the sum of the service component and the transfer. In the above example, the average time required for processing calls is

(5 ms + 50 ms = 55ms), the maximum time required for call processing is

(10ms + 10ms 100ms = 1).

According to the invention, the editing operation QoS information contained in the messages TRJP is to concatenate the values ​​of local QoS parameters of the field receiving TRIP ad with those already contained in the route announcement (ie those contained the message "UPDATE"). The method concatenation depends on the nature of the QoS parameter. These include for example the QoS parameters additive and multiplicative QoS parameters. For additives QoS parameters, the result of the concatenation is the adition of the local parameter value and that already contained in the route announcement message received from a neighbor LS.

To illustrate this scenario, assume that the average time. Assume that two ITADl and ITAD2 domains exchange TRIP routing information with QoS information. Assuming that the value of the average time to cross the ITADl is 15ms if ITAD2 ad to ITΛD1 destination data with a value of the average period equal to 55ms, ITADl in turn may announce these destinations to other neighbors by promoting the average time parameter to 15ms + 55ms = 70ms. For QoS parameters multiplying the result of the concatenation operation is the multiplication of the local parameter value and that already contained in the route announcement message received from a neighbor.

To illustrate this case, consider the example of a multiplicative parameter the QS. Assume that two ITADl and ITAD2 domains exchange TRIP routing information with QoS. Assuming that the value of the QSL to cross the ITADl of Vall if ITAD2 ad to ITADl destination data with a value equal to QSL VAL2, ITADl in turn may announce these destinations to other neighboring valuing the parameter average time to VAL1 VAL2 *).

It presents yet another example of updating the QoS information by a location server LS of the invention. Suppose a local LS receives from a neighboring LS, a road with the following QoS information: - Average time = 200ms;

Maximum time = 300ms;

1. If the local LS is in the same ITAD LS that the neighbor who announced the road, the QoS information is not modified;

2. If the LS is in a ITAD different from that of the neighboring LS: a. If both ITAD use the same AS, then only the service component QoS information will be taken into account for the update of QoS information. So i. the average time updated = 200ms + 205ms 5ms = ii. the maximum time set aperture = 300ms-310ms b rl = 0 ms. If both ITAD use AS, then the two components transfer service and QoS information will be taken into account for the update of QoS information. So i. the average time updated = 200ms + 5ms + 50 = 255ms; ii. the maximum time updated = 300 ms + 10 ms + 100 = 410ms. 5.3 Identification Mechanism AS borrowed by a given route

To allow the transfer of QoS parameters and served quality roads selecting a new attribute is introduced, in which contained information on the IP connectivity service providers used to carry voice traffic. More clearly, it allows the service layer to identify the AS, or IP connectivity operators used for voice traffic. An LS then has a simple and effective way to optimize a path from start to finish for a given destination. This information allows even more to detect anomalies such as eg IP spirals, since the service layer is aware of the AS through which the data passes.

5.3.1 Format

Classically, it is recalled that the TRIP protocol is implemented by the LS (location server) that propagate TRIP routes containing attributes that describe the routes in question. Specifically, the standard version of the TRIP protocol (detailed in the document RFC3219 Rosenberg et al. "Telephony Routing over IP (TRIP)" of January 2002) provides for the exchange of routing information between two neighboring LS via message UPDATE, which includes a number of attributes.

To see the list of IP connectivity service providers used to route voice traffic of an ITAD, we introduced a new attribute called AS_PATH. This attribute has the following attributes:

Conditional Mandatory: True

TRIP Type Code: To be defined by IANA.

Conditional Mandatory: This attribute indicates whether the attribute in question must be informed or not in a TRIP message.

TRIP Type Code: TRIP unique identifier of the message in question.

This attribute is intended to create and store a list of AS traversed to reach a given destination. It then spread to an IP domain to a neighboring IP domain. AS PATH attribute is composed of a sequence of segments, or fields, "AS path" (path AS). Each segment "AS path" is composed of a triple <path segment type path segment length, path segment value>, defined as follows: each "path segment-type" has a length of 1 byte which can take the following values:

each "path segment length" has a length of one 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 with a length of 2 bytes.

This new attribute list so the succession of AS traversed to reach a given destination.

5.3.2 General procedure route selection

Recall that operators each have one or more LS. Each LS maintains a routing table that feeds with ads received neighboring LS and those of his own domain. These ads are updated and redistributed to other neighbors if interconnection agreements allow.

Thus, when an LS propagates a TRIP route he learned in an update message from another neighbor LS, is expected to change the new AS_PATH attribute of the route according to the LS type which it must re-spread road, according Ia following procedure.

When a given ad LS road to another peer TRIP LS located in its own ITAD, the LS does not change the attribute ASJPATH linked to that road. If the LS to which the route is announced (LS pair) is not located in the same ITAD, two scenarios are presented to update the AS_PATH attribute: if the first segment of I 1 is ASJPATH Type aS ^ sEQUENCE, the local system adds the number of the IP connectivity service provider as the last element of the sequence; if the first segment of the AS_PATH is of type AS_SET, the local system adds a new segment type AS_SEQUENCE early AS_PATH; this new segment contains the number of domain IP connectivity service provider.

If the LS is the origin of the announcement, it includes the number of its IP connectivity service provider in the AS_PATH attribute of all UPDATE messages sent to peers located in TRIP ITAD neighbors. In addition, the LS includes an empty AS_PATH in all UPDATE messages sent to peers TRIP located in its own ITAD.

5.4 Process choice of quality of service roads

In order to improve the quality of service end-to-end telephony services, the inventors have found that it is desirable that the process of selecting a road inter TRIP ITAD must take into account the quality of service information to guide the selection of the route to be stored in the TRIP routing data bases. Therefore, the route selection process as described in RFC3219 standard is not appropriate since it does not take into account the quality of service criteria.

Here we describe two new methods for selecting routes based on QoS information exchanged between neighboring ITAD, according to the procedure described above, thanks to the attribute modified "TRIP Route".

It is assumed that an IP telephony operator assigns priorities to each QoS parameter reported in TRIP messages. For example, an operator can assign to the parameter "Minimum one way delay" (for "minimum path delay") greater priority and low priority to the parameter "Loss Rate" (for "loss rate") and so on . The valuation of priorities can also be done by a standards body such as HETF (for "Internet Engineering Task Force" in English) or PITU (for "International Telecommunication Union"). The algorithms presented below are based on this principle priority allocation for QoS parameters conveyed in TRIP messages, especially in the attributes "TRIP Route" amended in accordance with the procedure described in paragraph 5.2 of this description. 5.4.1 Algorithm 1 The algorithm shown in Figure 7 for the selection TRIP routes, considers the infoπnations QoS exchanged by TRIP and installs them in the local TRIB.

It begins with a first step 90 of identifying roads to the same destination. U s' follows a step 91 of examining the performance characteristic of

Service quality has the highest priority. In this same stage 91, roads that optimize the Quality of Service performance characteristics are identified.

Two cases are then considered. If one route is returned (i), the algorithm performs a step 93 storage this road in the local TRIB. If more than one route is returned (ii), a step 92 "excludes" the performance characteristic of QoS that is used in step 91 of the list of QoS performance characteristics. a) If, as a result of this step 92 "exclusion", there is no performance characteristic of remaining Quality of Service, the conventional method TRIP route selection is performed, in a step 94, if more a road has been identified in step 90; b) If not, the algorithm repeats step 91. 5.4.2 Algorithm 2

However, in another embodiment of the invention, it is possible to introduce a hierarchy to control QoS information exchanged by TRIP between two neighbors. The previous algorithm can then be modified. The additional hierarchical level introduced may then correspond to the definition of two types of QoS parameters:

"Mandatory" (mandatory) is the set of QoS parameters that must be filled by a neighboring LS in its update messages. If an ad does not contain a TRIP QoS parameter of this type, the ad is removed;

"Optionnal" (Optional) is a class in which the optional QoS information is group which may be indicated by a neighboring LS in its update messages. If an ad does not contain a TRIP QoS parameter of this type, this ad is not deleted.

It aims to control level to ensure consistency with respect to QoS information exchanged between IP telephony operators, that is to say between ITAD. However, the mandatory or optional parameters may well be introduced without any prioritization settings. In connection with Figure 8, the invention proposes a new algorithm taking into account the hierarchical level for a selection of optimal route in terms of end QoS to end.

It firstly comprises a step 100 of identifying roads that serve the same destination. If the remaining number of roads is not zero, it follows a step 1 10 of verification for each route, if all characteristics "mandatory" Quality of Service performance are present / valued.

If so, verify current route is added to the list of remaining routes in step 1 January 10. If not, this roll is discarded (step 1120). The remaining routes are then examined in a step 120.

If the remaining number of roads is not zero, a step 1200 examines the quality of service performance characteristic that has the highest priority, and returns the routes that optimize this quality performance characteristic service: a) one road is returned, a step 1210 stores this road in the local TRlB; b) If more than one route is returned, a step 1220 excludes Quality of Service performance feature of which was used in step 1200 the list of QoS performance characteristics.

Following this step 1220, if there is still no performance characteristic Quality of Service, the conventional method TRIP route selection is implemented (step 130), if more than one road was returned at step 100.

However, if there is a performance characteristic quality service, step 1200 is repeated.

Following step 120, if the remaining number of routes is zero, the algorithm performs the conventional process route selection TRIP at step 130, with the proviso that more than one drive has been returned when step 100.

In conclusion, these two methods are advantageous to an IP telephony operator wishing to deploy a mechanism for exchange of QoS information with neighboring operators. These algorithms are invoked to select the TRIP routes to install in the tables of local routes. With these, the phone companies are able to select optimal routes and whose quality of service is better. These algorithms can, in one embodiment, be implemented optimization of call costs. ANNEX RFC3219

Length ( "Length"): Corresponds to the length of the field "Address", in bytes;

Address ( "Address"): Represents an address (prefix) of the given family type identified by the Family field address ( "Address Family"). The length in bytes of the address is variable and is determined by the field length of the road.

Claims

1. A method of 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 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 method comprising a step of sending update messages conveying routes digital stream to said second server location, characterized in that said update messages contain QoS management information, and in that said service quality management information is updated by said first server before propagation to said second server based on at least one quality of service feature of said first field of telephony and / or said first autonomous system.
2. A method for propagation of at least one conveying route according to claim 1, characterized in that said QoS management information includes at least one of the following information: information QoS component linked to at least an autonomous system, said system component; information QoS component linked to at least one IP telephony domain, said domain component;
3. A method of propagating according to claim 2 characterized in that when said first domain IP telephony and said second IP telephony domain are identical, said updating does not change the quality of service management information.
4. A method of propagating, according to claim 2, characterized in that when said first IP telephony domain and said second IP telephony domain are distinct and that said first autonomous system and said second autonomous system are identical, said update not takes into account the at least one field component.
5. A method of propagating, according to claim 2, characterized in that when said first IP telephony domain and said second IP telephony domain are distinct and that said first autonomous system and said second autonomous system are separate, said adaptation takes into account said at least one field component and said at least one system component.
6. A method of propagating according to any one of claims 1 to 5, characterized in that it comprises a prior step of negotiating a QoS management capacity, according to at least one predetermined parameter, between said first and said second server location so that the said location servers exchange messages containing updated QoS information.
7. A method of propagating according to any one of claims 1 to 6, characterized in that it comprises a step of selecting at least one route to propagate in accordance with said quality of service management information.
8. A method of propagation according to claim 7, characterized in that at least one of said quality of service parameter is a required quality of service parameter, and in that said selection step takes account of said at least one quality parameter compulsory service.
9. A method of propagating according to any one of claims 7 and 8, characterized in that said at least one quality of service parameter has a hierarchy level, and in that said selection step takes account of said hierarchy level.
10. Location Server of a first IP telephony domain, capable of propagating at least one conveying route of at least one digital stream to between a second location server of a second IP telephony domain, said first server location 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 conveying routes digital stream to said second server location, characterized in that said update messages contain service quality management infoπnations, and in that said service quality management information is updated by said first server before propagation to said second server based on at least one characteristic of said first field of telephony and / or said first system autonomous.
11. Product computer program downloadable from a communications network and / or stored on a computer readable medium and / or executable by a microprocessor, characterized in that it comprises program code instructions for executing the method production process according to at least one of claims 1 to 9 when executed on a computer.
EP20070731926 2006-04-21 2007-04-20 Method for taking into account the quality of service between distinct ip telephony domains, corresponding locating server and computer programme Withdrawn EP2052505A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0603623 2006-04-21
PCT/FR2007/051151 WO2007122355A1 (en) 2006-04-21 2007-04-20 Method for taking into account the quality of service between distinct ip telephony domains, corresponding locating server and computer programme

Publications (1)

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

Family

ID=37684109

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20070731926 Withdrawn EP2052505A1 (en) 2006-04-21 2007-04-20 Method for taking into account the quality of service between distinct ip telephony domains, corresponding locating server and computer programme

Country Status (3)

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

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US8457105B2 (en) * 2006-04-21 2013-06-04 France Telecom Method of propagating IP connectivity information between distinct IP telephony domains, and a corresponding location server and computer program

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 (en) * 2004-09-08 2007-12-26 华为技术有限公司 System and realization for dynamic cooperating service quality in next generation network
US7409482B2 (en) * 2004-10-26 2008-08-05 Lenovo (Singapore) Pte, Ltd. Computer and method for on-demand network access control

Non-Patent Citations (1)

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

Also Published As

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

Similar Documents

Publication Publication Date Title
Hawkinson et al. Guidelines for creation, selection, and registration of an Autonomous System (AS)
US7184434B2 (en) Label distribution protocol supporting multiple classes of service in a multi protocol label switching (MPLS) network, methods and MPLS network using thereof
US7281043B1 (en) System for sharing resources among RSVP sessions
US20070286185A1 (en) Control of Mobile Packet Streams
US7522603B2 (en) Technique for efficiently routing IP traffic on CE-CE paths across a provider network
US6714515B1 (en) Policy server and architecture providing radio network resource allocation rules
US7953877B2 (en) System and method for controlling data flow based upon a temporal policy
US20060291447A1 (en) Virtual circuits in packet networks
US20030137971A1 (en) Telecommunications system and method
US6556544B1 (en) Method and system for provisioning network resources for dynamic multicast groups
US7142532B2 (en) System and method for improving communication between a switched network and a packet network
US6714987B1 (en) Architecture for an IP centric distributed network
US7565448B1 (en) Network control system for a communication network
US20060039397A1 (en) Sagacious routing engine, method of routing and a communications network employing the same
US20070133406A1 (en) Technique for enabling traffic engineering on CE-CE paths across a provider network
US20070058639A1 (en) Systems and methods for interworking QSIG and H.323 signaling in a SIP-based network
US7260060B1 (en) Call admission control
US20040215817A1 (en) Method for providing guaranteed quality of service in IP network and system thereof
US6680943B1 (en) Establishing bi-directional communication sessions across a communications network
US20040215787A1 (en) Establishing connections across a communications network
US20080037425A1 (en) Control Plane to data plane binding
US7586899B1 (en) Methods and apparatus providing an overlay network for voice over internet protocol applications
US20070291734A1 (en) Methods and Apparatus for Multistage Routing of Packets Using Call Templates
US20070019563A1 (en) Methods and Apparatus for Controlling Call Admission to a Network Based on Network Resources
US20050213591A1 (en) Router and sip server

Legal Events

Date Code Title Description
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 to

Extension state: AL BA HR MK RS

17Q First examination report

Effective date: 20091202

DAX Request for extension of the european patent (to any country) deleted
RAP1 Transfer of rights of an ep published application

Owner name: ORANGE

RIC1 Classification (correction)

Ipc: H04L 12/70 20130101AFI20170110BHEP

INTG Announcement of intention to grant

Effective date: 20170206

18D Deemed to be withdrawn

Effective date: 20170617