EP2328300A1 - A method for checking a path according to encapsulation functions using a push-down automaton - Google Patents

A method for checking a path according to encapsulation functions using a push-down automaton Download PDF

Info

Publication number
EP2328300A1
EP2328300A1 EP09177409A EP09177409A EP2328300A1 EP 2328300 A1 EP2328300 A1 EP 2328300A1 EP 09177409 A EP09177409 A EP 09177409A EP 09177409 A EP09177409 A EP 09177409A EP 2328300 A1 EP2328300 A1 EP 2328300A1
Authority
EP
European Patent Office
Prior art keywords
label
word
path
stack
push
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.)
Granted
Application number
EP09177409A
Other languages
German (de)
French (fr)
Other versions
EP2328300B1 (en
Inventor
Helia Pouyllau
Richard Douville
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.)
Alcatel Lucent SAS
Original Assignee
Alcatel Lucent SAS
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 Alcatel Lucent SAS filed Critical Alcatel Lucent SAS
Priority to EP09177409A priority Critical patent/EP2328300B1/en
Publication of EP2328300A1 publication Critical patent/EP2328300A1/en
Application granted granted Critical
Publication of EP2328300B1 publication Critical patent/EP2328300B1/en
Not-in-force legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003Managing SLA; Interaction between SLA and QoS
    • H04L41/5019Ensuring fulfilment of SLA
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • 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/52Multiprotocol routers

Definitions

  • the present invention relates to a method for checking a path built between a source node and another node for a network system.
  • the invention also relates to a method for building a push-down automaton.
  • Such a method for checking a path may be used in any network system supporting a plurality of protocols technologies.
  • an end-to-end path has to be computed satisfying quality of service QoS requirements (e.g. bandwidth superior to a threshold value) expressed by a demand.
  • quality of service QoS requirements e.g. bandwidth superior to a threshold value
  • a method for checking a path built between a source node and another node for a network system is used to check said path according to quality and cost metrics based on the QoS requirements.
  • nodes and/or edges of a network system have often several adaptation functions, so that they can interconnect using different protocol technology (e.g. IP, Ethernet, MPLS, etc.).
  • possible adaptation functions are: a first protocol encapsulating a second protocol, a first protocol desencapsulating a second protocol, the second protocol encapsulating the first protocol, and the second protocol desencapsulating the first protocol.
  • a method for checking a path built between a source node and another node for a network system comprising the steps of:
  • the definition of the adaptation functions associated to the built path are in the form of labels of words in order to permit to simply read said labels with a push-down automaton and at the same time modifying a stack associated to said push-down automaton.
  • the definition of the adaptation functions associated to the built path are in the form of labels of words in order to permit to simply read said labels with a push-down automaton and at the same time modifying a stack associated to said push-down automaton.
  • a set of words is read.
  • the validation of the built path comprises the sub-step of:
  • the validation of the built path further comprises the sub-steps of:
  • the push-down automaton comprises:
  • This push-automaton permits to simply read a word and fill in the associated stack.
  • a push-down automaton able to read a word associated to a built path, a word comprising labels of an alphabet representing technologies and adaptation functions supported by edges and/or nodes of a network system, a label of a word being associated to an edge or a node of the built path, said push-down automaton comprising:
  • a method for building a push-down automaton for reading a word associated to the built path comprising:
  • This method permits to simply build the push-automaton.
  • a label of an alphabet representative of an adaptation function is composed of three letters, the first and third letters representing the technologies supported by the adaptation function, and the second letter representing a type of the adaptation function. This is a simple way to define an adaptation function within the alphabet.
  • a label of an alphabet representative of a technology used within a node and/or an edge is composed of a single letter. This is a simple way to define a technology within the alphabet.
  • a technology is Ethernet, IP, Multiprotocol Label Switching, or Synchronous Digital Hierarchy.
  • an adaptation function is:
  • a network management element for checking a path built between a source node and another node for a network system, according to adaptation functions, said network management element comprising the push-down automaton according to the previous characteristics.
  • a network management element for checking a path built between a source node and another node for a network system, according to adaptation functions, said network management element being able to carry out the method for checking a path according to any one of the previous characteristics.
  • a network management element for checking a path built between a source node and another node for a network system, according to adaption functions, said network management element being able to carry out the method for building a push-down automaton according to any one of the previous characteristics.
  • the network management element is:
  • a network system for checking a path built between a source node and another node for a network system, according to adaptation functions, said network system being able to manage a network management element according to any one of the previous characteristics.
  • a computer program product for a computer comprising a set of instructions, which when loaded into said computer, causes the computer to carry out the method for checking a path according to any one of the previous characteristics.
  • a computer program product for a computer comprising a set of instructions, which when loaded into said computer, causes the computer to carry out the method for building a push-down automaton according to any one of the previous characteristics.
  • the present invention relates to a method for checking a path built between a source node and another node for a network system, according to adaptation functions.
  • said method for checking path will also be called first method.
  • the aim is to check if both nodes could communicate using their corresponding protocol technology. It is to be noted that the terms protocol or technology will be also used indifferently.
  • a network system NTW ⁇ N
  • E ⁇ is composed of a set of nodes N and a set of edges E
  • a built path ⁇ is a sequence of edges E and nodes N between the source node NS and the another node Nl.
  • the method MA for checking a path comprises the following steps, as illustrated in Fig. 1 :
  • nodes N and/or edges of the network system NTW are supported by nodes N and/or edges of the network system NTW, depending of a choice of model taken for the network system NTW.
  • the labels may be associated to an edge or to a node of the built path, depending of a choice of model taken for the push-down automaton.
  • a word ⁇ ( ⁇ ) may be built using the labels ⁇ ( ⁇ ) on the edges or the nodes belonging to said path ⁇ . Since several adaptation functions may be associated to a node and/or an edge, a path ⁇ might leads to a set of words W. Therefore in a not limited embodiment, a set of words W is read.
  • the first method MA may be used for checking an intermediate path or a final path.
  • An intermediate path is a path being built between the source node NS and another node Nl, said other node Nl being in this case an intermediate node between the source node NS and a destination node ND to which a service has to be delivered.
  • An intermediate path is therefore a part of a final path. Therefore, in this case, in a not limited embodiment, the validation of the built path ⁇ comprises the sub-step of, as illustrated in Fig. 3 :
  • the checking of an intermediate path permits to stop the building of a path if one realizes that the intermediate node will not be able to communicate with the source node according to their protocols.
  • a final path is the end-to-end path between the source node NS and another node Nl, said other node Nl being in this case the destination node ND to which a service has to be delivered.
  • the validation of the built path ⁇ further comprises the sub-steps of, as illustrated in Fig. 3 :
  • the top entry of the stack STK is tested. If his top entry is a label representative of an adaptation function xoy, xdy one validates the path ⁇ .
  • the first method MA is described in details below.
  • the first method MA comprises the further steps and sub-steps above-mentioned.
  • a set of words W (associated to the built path ⁇ which is to be checked) is composed of two words ⁇ 1 and ⁇ 2 as following.
  • an initialization step 0 as illustrated in Fig. 3 , one initializes a first and a second counters i and j to zero for counting respectively the number of words ⁇ ( ⁇ ) forming the set of words W associated to the built path ⁇ , and the number of labels 1( ⁇ ) within the set of words W.
  • the first method MA starts from the initial state ⁇ and takes as an input the set of words W.
  • a push-down automaton AUT for reading a word ⁇ ( ⁇ ) associated to the built path ⁇ , a word ⁇ ( ⁇ ) comprising labels 1( ⁇ ) of an alphabet ⁇ representing technologies tck and adaptation functions supported by edges and/or nodes of the network system NTW, a label 1( ⁇ ) of a word ⁇ ( ⁇ ) being associated to an edge E or a node N of the built path ⁇ .
  • the push-down automaton AUT is described below.
  • FIG. 2 A schematic diagram of a not limited embodiment of the push-down automaton AUT is illustrated in Fig. 2 .
  • Such a push-down automaton AUT comprises:
  • stack commands ⁇ are associated to the stack STK:
  • each state st but the initial state ⁇ is labeled with a label 1( ⁇ ) representing a technology tck used within a node and/or an edge of the network system NTW.
  • the technology tck used is the protocol supported by a node and/or an edge, here MPLS of Ethernet.
  • a first sub-step 1a as illustrated in Fig.3 , one reads a label 1( ⁇ ) forming said word ⁇ ( ⁇ )
  • a second sub-step 1b as illustrated in Fig. 3 , one checks if there is a transition tr associated to the label read I( ⁇ ).
  • transition tr1 associated to the first label read "m" as illustrated in Fig. 2 .
  • a third sub-step 1c) as illustrated in Fig. 3 , one activates stack commands ⁇ on the stack STK according to the conditions read Cond.
  • activating stack commands leads to fill in the stack STK with a label 1( ⁇ ) or to remove from the stack STK a label I( ⁇ ), as described hereinafter.
  • a fourth sub-step 1d as illustrated in Fig. 3 , one goes to the egress state st* of the transition tr.
  • a fifth sub-step 1e one iterates the preceding sub-steps 1a) to 1d) with the next label 1( ⁇ ) of the word ⁇ ( ⁇ )
  • the second counter j is increased by one.
  • the stack STK is empty for the first word ⁇ 1.
  • the validation comprises the following sub-steps.
  • a first sub-step 2a:OK when a word ⁇ ( ⁇ ) has been read entirely and the another node Nl is different from the destination node ND, one validates the path ⁇ being built with the adaptation functions corresponding to the word read ⁇ ( ⁇ ).
  • this sub-step is performed when the path ⁇ is being built, i.e. when it is an intermediate path, as the another node Nl is different from the destination node ND.
  • a second sub-step 2a:NOK when the word ⁇ ( ⁇ ) has been read entirely and the another node Nl is equal to the destination node ND, the following sub-steps are performed.
  • this sub-step is performed when the path ⁇ is a final path.
  • the first word ⁇ 1 has been read entirely. Therefore the built path ⁇ is validated with the adaptation functions corresponding to this word, that is to say, with the adaptation functions moe, eom, mde, edm. In this case, both nodes NS and ND could communicate using their corresponding protocols.
  • the first word ⁇ 1 has been read entirely.
  • a third step 3 one iterates the preceding steps 1 and 2 with said next word ⁇ ( ⁇ ) of the set of words W, i.e. the second word ⁇ 2.
  • the stack STK is not empty for the second word ⁇ 2 but is fill in with the label moe.
  • the validation comprises the following sub-steps.
  • the second word ⁇ 2 has been read entirely. Therefore the built path ⁇ is validated with the adaptation functions corresponding to this word, that is to say, with the adaptation functions moe, eom, mde.
  • the second word ⁇ 2 have been read entirely.
  • a built path ⁇ is validated, that means is feasible, when at least a word ⁇ ( ⁇ ) of the set of word W is "validated" according to the conditions above-described.
  • a built path ⁇ is invalidated, that means is not feasible, when all the words ⁇ ( ⁇ ) of the set of words W associated to said path are "invalidated” according to the conditions above-described. This means when the built path ⁇ has been validated by none of the word ⁇ ( ⁇ ) of a set of words W.
  • a word is invalidated (step INVALlD_W( ⁇ ( ⁇ ))) when:
  • the validation of a built path ⁇ is performed each time a word ⁇ ( ⁇ ) of the set of words W has been proceeded by the push-automaton AUT.
  • the validation of a built path ⁇ is performed after all the words ⁇ ( ⁇ ) of the set of words W have been proceeded by the push-automaton AUT.
  • all the words read (entirely or not) are saved in a memory waiting for the step 2) to be performed.
  • the step 2) of validation returns the number NBW of words ⁇ ( ⁇ ) of the set of words W which have validated the path ⁇ , words which may be also called words validated. It permits to acquire a quality factor.
  • the first method MA permits to check the adaptation functions of a built path ⁇ and to validate said path ⁇ , either for an intermediate path, or for a final path and this thanks to the push-down automaton AUT.
  • push-down automaton AUT described is built by a method MC for building a push-down automaton AUT for reading a word ⁇ ( ⁇ ) associated to the built path ⁇ , a word ⁇ ( ⁇ ) comprising labels 1( ⁇ ) of an alphabet ⁇ representing technologies tck and adaptation functions supported by edges and/or nodes of the network system NTW, a label 1( ⁇ ) of a word ⁇ ( ⁇ ) being associated to an edge E or a node N of the built path ⁇ , said push-down automaton AUT comprising :
  • said method for building a push-down automaton will also be called second method.
  • Said second method MC is illustrated in a not limited embodiment in Fig. 4 . It comprises the steps of:
  • a label 1( ⁇ ) of an alphabet ⁇ representative of an adaptation function is composed of three letters xoy, xdy, the first and third letters representing the technologies tck supported by the adaptation function, and the second letter (o or d) representing a type TY of the adaptation function.
  • a label 1( ⁇ ) of an alphabet ⁇ representative of a technology tck used within a node and/or an edge is composed of a single letter.
  • the label 1( ⁇ ) of an alphabet ⁇ representative of an adaptation function MPLS over Ethernet is composed of three letters moe, the first and third letters, respectively m and e, representing the technologies tck supported by the adaptation function, respectively MPLS and Ethernet, and the second letter representing a type TY of the adaptation function, i.e. here "o" for the encapsulation.
  • the label 1( ⁇ ) of an alphabet ⁇ representative of the inverse adaptation function of eom MPLS from Ethernet is composed of three letters mde, the first and third letters, respectively m and e, representing the technologies tck supported by the adaptation function, respectively MPLS and Ethernet, and the second letter representing a type TY of the adaptation function, i.e. here "d" for desencapsulation.
  • the second method MC is described in details hereinafter.
  • a first step 1) one builds stack commands ⁇ as following.
  • a second step 2) one builds states st of the push-down automaton AUT as following.
  • a label 1( ⁇ ) of an alphabet ⁇ is a single letter representative of a technology tck used within a node and/or an edge, in the example e or m
  • a state respectively st1 * and st2*, which is named with said label e or m.
  • a third step 3 one builds transitions tr of the push-down automaton AUT as following.
  • a fourth step 4 one associates stack commands ⁇ to said transitions tr built according to conditions Cond as following.
  • Cond1 and Cond2 are used.
  • the stack command MOE is associated to the transition tr3.
  • the stack command EOM is associated to the transition tr4.
  • the remove command EOM is associated to the transition tr6, otherwise the push command MDE is associated.
  • the remove command MOE is associated to the transition tr5, otherwise the push command EDM is associated.
  • the method MA for checking a path and the method MC for building a push-down automaton above-described are carried out by a network management element NME of a system NTW.
  • said network system NTW is a multi-domain network and is able to manage:
  • the network system NTW is able to manage:
  • a domain is a collection of network management elements NME within a common sphere of address management or computational responsibility as defined in the IETF standard.
  • a domain may be an Autonomous System (AS), an interior gateway protocol IGP routing area, or a Generalized Multiprotocol Label Switching overlay network layer.
  • AS Autonomous System
  • IGP routing area an interior gateway protocol IGP routing area
  • Generalized Multiprotocol Label Switching overlay network layer an interior gateway protocol IGP routing area
  • a network management element NME is aware of:
  • a network management element uses a database.
  • a network management element NME is:
  • the nodes N described in a not limited example are routers.
  • a router NS of the domain D1 wants to transmit some data to router ND of another domain D2 (called a destination node or here a destination router)
  • it delivers a service to the destination router ND.
  • the first method MA is thus start up by a source network management element NMEs within the source domain D1, intermediate network management elements NMEy within intermediate domain Dy, and the destination network management element NMEd within the destination domain D2.
  • the source, intermediate and destination network management elements NME are described hereinafter according to Fig. 6 .
  • a network management element NME for checking a path ⁇ built between a source node NS and another node Nl for a network system NTW comprises the push-down automaton AUT.
  • a network management element NMEs for checking a path ⁇ built between a source node NS and another node Nl for a network system NTW, according to adaptation functions, is able to carry out the method MA for checking a path.
  • said network management element NMEs comprises in particular a control unit UC which is able to:
  • control unit UC is further able to perform the corresponding sub-steps of the validation as described before.
  • a network management element NMEs for checking a path ⁇ built between a source node NS and another node Nl for a network system NTW, according to adaptation functions, is able to carry out the method MC for building a push-down automaton.
  • said network management element NMEs comprises in particular a control unit UC which is able to:
  • the first method MA may be used for inter-domain path computation such as in not limited examples:
  • adaptation functions may be used, based on other technologies, such as in not limited examples IP or the Synchronous Digital Hierarchy protocol SDH.
  • the step of building stack commands may be combined with the step of building states of the push down automaton, thus forming a single function without modifying the building method MC in accordance with the invention.
  • a first computer program product PG1 can be contained in a computer or in a network management element NME and in the same manner, a second computer program product PG2 can be contained in a computer or in a network management element NME, said NME comprising a unit control as described previously, said unit control being hardware or software items as above stated.
  • the first computer program product PG1 comprises a first set of instructions.
  • said first set of instructions contained, for example, in a computer programming memory or in a network management element memory NME may cause the computer or the network management element NME to carry out the different steps of the method MA for checking a path (and thus the different steps of the push-down automaton AUT).
  • the second computer program product PG2 comprises a second set of instructions.
  • said second set of instructions contained, for example, in a computer programming memory or in a network management element memory NME memory, may cause the computer or the network management element memory NME to carry out the different steps of the method MC for building a push-down automaton.
  • the different sets of instructions may be loaded into the programming memory by reading a data carrier such as, for example, a disk.
  • a service provider can also make the set of instructions available via a communication network such as, for example, the Internet.
  • a third computer program product (not illustrated) can be contained in a computer or in a network management element NME, said third computer program product comprising a third set of instructions.
  • the push automaton AUT comprises a unit control which is able to read a label, check if there is a transition, activate stack commands etc. as described before, said unit control being hardware or software items as above stated.
  • the third computer program product (not illustrated) can be contained in a computer or in the push-down automaton.
  • some embodiments of the invention may comprise one or a plurality of the following advantages:

Abstract

The present invention relates to a method (MA) for checking a path built between a source node and another node for a network system, according to adaptation functions. It is characterized in that it comprises the steps of:
- launching a push-down automaton (1) for reading a word associated to the built path, a word comprising labels of an alphabet representing protocols and encapsulation functions supported by edges and/or nodes of the network system, a label of a word being associated to an edge or a node of the built path; and
- validating the built path (2) according to the result of the reading of the word and to the state of a stack of said push-automaton, said stack (STK) being modified during the reading of the word.
It also relates to a method for building a push-down automaton.

Description

    FIELD OF THE INVENTION
  • The present invention relates to a method for checking a path built between a source node and another node for a network system. The invention also relates to a method for building a push-down automaton.
  • Such a method for checking a path may be used in any network system supporting a plurality of protocols technologies.
  • BACKGROUND OF THE INVENTION
  • When a service has to be established (such as for example a data transmission) between a source node and another node of a network system, an end-to-end path has to be computed satisfying quality of service QoS requirements (e.g. bandwidth superior to a threshold value) expressed by a demand.
  • A method for checking a path built between a source node and another node for a network system, well-known by the man skilled in the art, is used to check said path according to quality and cost metrics based on the QoS requirements.
  • Besides, nodes and/or edges of a network system have often several adaptation functions, so that they can interconnect using different protocol technology (e.g. IP, Ethernet, MPLS, etc.). In a not limited example, possible adaptation functions are: a first protocol encapsulating a second protocol, a first protocol desencapsulating a second protocol, the second protocol encapsulating the first protocol, and the second protocol desencapsulating the first protocol.
  • Although, it is preferable that the same protocol is used along the path avoiding adding costs of encapsulation, it might not be possible sometimes to satisfy both the QoS requirements meanwhile having the same protocol. Hence, adaptation functions of nodes and/or edges must be used to permit the delivery of a service.
  • One problem of the well-known prior art is that it may lead to unfeasible path because of the adaptation functions which do not match along the path. Both nodes can't communicate together using their protocol technologies.
  • SUMMARY OF THE INVENTION
  • It is an object of the invention to provide a method for checking a path built between a source node and another node for a network system, which permits to check if a built path is feasible according to adaptation functions supported by said nodes.
  • To this end, there is provided a method for checking a path built between a source node and another node for a network system, according to adaptation functions, said method comprising the steps of:
    • launching a push-down automaton for reading a word associated to the built path, a word comprising labels of an alphabet representing technologies and adaptation functions supported by edges and/or nodes of the network system, a label of a word being associated to an edge or a node of the built path; and
    • validating the built path according to the result of the reading of the word and to the state of a stack of said push-automaton, said stack being modified during the reading of the word.
  • As we will see in further details, the definition of the adaptation functions associated to the built path are in the form of labels of words in order to permit to simply read said labels with a push-down automaton and at the same time modifying a stack associated to said push-down automaton. In order to know if a path is valid or not according to its adaptation functions, there is a check on the stack and the result of the reading of a word.
  • In a first not limited embodiment, a set of words is read.
  • It permits to simply check if a path is feasible or not when a plurality of adaptation functions is associated to a node within said path.
  • In a second not limited embodiment, the validation of the built path comprises the sub-step of:
    • when the word has been read entirely and the another node is different from a destination node, validating the path being built with the adaptation functions corresponding to the word read.
  • This permits to validate an intermediate path, which is a path built between the source node and an intermediate node which is not the destination node.
  • In a third not limited embodiment, the validation of the built path further comprises the sub-steps of:
    • when the word has been read entirely and the another node is equal to a destination node:
      • if the source node and the destination node are of homogeneous technologies and if the stack is empty, validating the path with the adaptation functions corresponding to the word read ;
      • if the source node and the destination node are of heterogeneous technologies and if the stack comprises a label representative of an adaptation function, validating the path with the adaptation functions corresponding to the word read.
  • This permits to validate a final path, which is a path built between the source node and the destination node to which a service is to be delivered.
  • In a fourth not limited embodiment, the push-down automaton comprises:
    • a stack and associated stack commands;
    • the alphabet of labels representing technologies and adaptation functions supported by edges and/or nodes of the network system;
    • states and transitions which labels of the alphabet are associated to;
    and is able to:
    • read a label forming said word;
    • check if there is a transition associated to the label read;
    • if an associated transition exists :
      • activate stack commands on the stack according to conditions associated to the transition;
      • go to the egress state of the transition ; and
      • iterate the preceding steps with the next label of the word.
  • This push-automaton permits to simply read a word and fill in the associated stack.
  • In addition, there is provided a push-down automaton able to read a word associated to a built path, a word comprising labels of an alphabet representing technologies and adaptation functions supported by edges and/or nodes of a network system, a label of a word being associated to an edge or a node of the built path, said push-down automaton comprising:
    • a stack and associated stack commands;
    • the alphabet of labels representing technologies and adaptation functions supported by edges and/or nodes of the network system;
    • states and transitions which labels of the alphabet are associated to;
    said push-down automaton being able to:
    • read a label forming said word;
    • check if there is a transition associated to the label read;
    • if an associated transition exists :
      • activate stack commands on the stack according to conditions associated to the transition;
      • go to the egress state of the transition; and
      • iterate the preceding steps with the next label of the word.
  • In addition, there is provided a method for building a push-down automaton for reading a word associated to the built path, a word comprising labels of an alphabet representing technologies and adaptation functions supported by edges and/or nodes of a network system, a label of a word being associated to an edge or a node of the built path, said push-down automaton comprising:
    • a stack and associated stack commands;
    • the alphabet of labels representing technologies and adaptation functions supported by edges and/or nodes of the network system;
    • states and transitions which labels of the alphabet are associated to;
    said method comprising the steps of:
    • building stack commands, where :
      • when a label of an alphabet is representative of an encapsulation adaptation function, build a push command which is able to fill in a stack with said label;
      • when a label of an alphabet is representative of a desencapsulation adaptation function, build a remove command which is able to remove the inverse label from the stack and build a push command which is able to fill in a stack with said label;
    • building states of the push-down automaton, where :
      • when a label of an alphabet is representative of a technology used within a node and/or an edge, build a state which is named with said label;
    • building transitions of the push-down automaton, where :
      • for each label of an alphabet representative of an adaptation function, build a transition having as start state the first letter of said label, and having as end state the last letter of said label, and labeled said transition with said label;
      • for each label of an alphabet representative of a technology used within a node and/or an edge, build a reflexive transition over its corresponding state, and labeled said transition with said label;
    • associating stack commands to said built transitions according to conditions, where :
      • when the label labeling a transition is representative of an encapsulated adaptation function, the corresponding stack command is associated to the transition;
      • when the label labeling a transition is representative of a desencapsulation adaptation function and if the top entry of the stack is filled in with the inverse adaptation function, the corresponding remove command is associated to the transition, otherwise the corresponding push command is associated to the transition.
  • This method permits to simply build the push-automaton.
  • In a first not limited embodiment, a label of an alphabet representative of an adaptation function is composed of three letters, the first and third letters representing the technologies supported by the adaptation function, and the second letter representing a type of the adaptation function. This is a simple way to define an adaptation function within the alphabet.
  • In a second not limited embodiment, a label of an alphabet representative of a technology used within a node and/or an edge is composed of a single letter. This is a simple way to define a technology within the alphabet.
  • In a third not limited embodiment, a technology is Ethernet, IP, Multiprotocol Label Switching, or Synchronous Digital Hierarchy.
  • In a fourth not limited embodiment, an adaptation function is:
    • Multiprotocol Label Switching over IP ; or
    • IP over Multiprotocol Label Switching ; or
    • Ethernet over IP ; or
    • IP over Ethernet ; or
    • Multiprotocol Label Switching over Ethernet ; or
    • Ethernet over Multiprotocol Label Switching ; or
    • Synchronous Digital Hierarchy over Ethernet ; or
    one of the corresponding desencapsulation adaptation functions.
  • In addition, there is provided a network management element for checking a path built between a source node and another node for a network system, according to adaptation functions, said network management element comprising the push-down automaton according to the previous characteristics.
  • In addition, there is provided a network management element for checking a path built between a source node and another node for a network system, according to adaptation functions, said network management element being able to carry out the method for checking a path according to any one of the previous characteristics.
  • In addition, there is provided a network management element for checking a path built between a source node and another node for a network system, according to adaption functions, said network management element being able to carry out the method for building a push-down automaton according to any one of the previous characteristics.
  • In a not limited embodiment, the network management element is:
    • a network management system ; or
    • a path computation element ; or
    • a router ; or
    • an operational support system ; or
    • an administrative owner.
  • In addition, there is provided a network system for checking a path built between a source node and another node for a network system, according to adaptation functions, said network system being able to manage a network management element according to any one of the previous characteristics.
  • In addition, there is provided a computer program product for a computer, comprising a set of instructions, which when loaded into said computer, causes the computer to carry out the method for checking a path according to any one of the previous characteristics.
  • In addition, there is provided a computer program product for a computer, comprising a set of instructions, which when loaded into said computer, causes the computer to carry out the method for building a push-down automaton according to any one of the previous characteristics.
  • BRIEF DESCRIPTION OF THE FIGURES
  • Some embodiments of methods and/or apparatus in accordance with embodiments of the present invention are now described, by way of example only, and with reference to the accompanying drawings, in which:
    • Fig.1 illustrates a schematic diagram of a method for checking a path according to the invention;
    • Fig.2 illustrates a schematic diagram of a push-down automaton used within the method for checking a path of Fig. 1 and according to the invention;
    • Fig.3 illustrates a detailed schematic organization chart of the method for checking a path of Fig. 1;
    • Fig.4 illustrates a schematic organization chart of a method for building a push-down automaton according to the invention;
    • Fig.5 illustrates a schematic network system comprising network management elements which perform the method for checking a path of Fig. 1 and/or the method for building a push-down automaton of Fig. 4;
    • Fig.6 illustrates schematically in more details a network management element, within a network system, which is able to perform the method for checking a path of Fig. 1 and the method for building a push-down automaton of Fig. 4.
    DESCRIPTION OF EMBODIMENTS OF THE INVENTION
  • In the following description, well-known functions or constructions by the man skilled in the art are not described in detail since they would obscure the invention in unnecessary detail.
  • The present invention relates to a method for checking a path built between a source node and another node for a network system, according to adaptation functions.
  • In the following description, said method for checking path will also be called first method.
  • The aim is to check if both nodes could communicate using their corresponding protocol technology. It is to be noted that the terms protocol or technology will be also used indifferently.
  • It is to be noted that a network system NTW={N, E} is composed of a set of nodes N and a set of edges E, and a built path π is a sequence of edges E and nodes N between the source node NS and the another node Nl. 1.
  • In order to perform a checking of a path built π between a source node NS and another node Nl for a network system NTW, according to adaptation functions, the method MA for checking a path comprises the following steps, as illustrated in Fig. 1:
    • launching a push-down automaton AUT for reading a word ω(π) associated to the built path π, a word ω(π) comprising labels 1(π) of an alphabet Σrepresenting technologies tck and adaptation functions supported by edges and/or nodes of the network system NTW, a label 1(π) of a word ω(π) being associated to an edge E or a node N of the built path π (step LNCH_AUT); and
    • validating the built path π according to the result of the reading of the word ω(π) and to the state of a stack STK of said push-automaton AUT, said stack STK being modified during the reading of the word ω(π) (step CHK_PTH(π,ω(π),STK).
  • It is to be noted that the technologies and adaptation functions are supported by nodes N and/or edges of the network system NTW, depending of a choice of model taken for the network system NTW.
  • It is also to be noted that the labels may be associated to an edge or to a node of the built path, depending of a choice of model taken for the push-down automaton.
  • As a path π built between a source node NS and another node Nl is a sequence of edges E and nodes N between these two nodes NS and Nl, a word ω(π) may be built using the labels ω(π) on the edges or the nodes belonging to said path π. Since several adaptation functions may be associated to a node and/or an edge, a path π might leads to a set of words W. Therefore in a not limited embodiment, a set of words W is read.
  • In the following description, protocols such as MPLS ("Multiprotocol Label Switching "), labeled "m" and Ethernet, labeled "e", are taken into a not limited example. The associated adaptation functions are:
    • MPLS over Ethernet, labeled "moe", where the MPLS protocol is encapsulated in the Ethernet protocol ;
    • Ethernet over MPLS, labeled "eom", where the Ethernet protocol is encapsulated in the MPLS protocol;
    • Ethernet from MPLS, which is the inverse adaptation function of "moe", labeled "edm", where the Ethernet protocol is desencapsulated in the MPLS protocol ;
    • MPLS from Ethernet, which is the inverse adaptation function of "eom", labeled "mde", where the MPLS protocol is desencapsulated from the Ethernet protocol.
  • It is to be noted that the first method MA may be used for checking an intermediate path or a final path.
  • An intermediate path is a path being built between the source node NS and another node Nl, said other node Nl being in this case an intermediate node between the source node NS and a destination node ND to which a service has to be delivered. An intermediate path is therefore a part of a final path. Therefore, in this case, in a not limited embodiment, the validation of the built path πcomprises the sub-step of, as illustrated in Fig. 3:
    • when the word ω(π) has been read entirely (step 1f:OK) and the another node Nl is different from a destination node ND (step 2a:OK), validating the path π being built with the adaptation functions corresponding to the word read ω(π) (step 2e: VALlD(π,ω(π)¡)).
  • The checking of an intermediate path permits to stop the building of a path if one realizes that the intermediate node will not be able to communicate with the source node according to their protocols.
  • A final path is the end-to-end path between the source node NS and another node Nl, said other node Nl being in this case the destination node ND to which a service has to be delivered.
  • Therefore, in this case, in a not limited embodiment, the validation of the built path πfurther comprises the sub-steps of, as illustrated in Fig. 3:
    • when the word ω(π) has been read entirely (step 1f:OK) and the another node Nl is equal to a destination node ND (step 2a:NOK) :
      • if the source node NS and the destination node ND are of homogeneous technologies tck (step 2b:OK) and if the stack STK is empty (step 2c:OK), validating the path π with the adaptation functions corresponding to the word read ω(π) (step 2e: VALlD(π,ω(π)¡)) ;
      • if the source node NS and the destination node ND are of heterogeneous technologies tck (step 2b:NOK) and if the stack STK comprises a label representative of an adaptation function xoy, xdy (step 2d:OK), validating the path π with the adaptation functions corresponding to the word read ω(π) (step 2e: VALlD(π,ω(π)¡)).
  • In a not limited embodiment, the top entry of the stack STK is tested. If his top entry is a label representative of an adaptation function xoy, xdy one validates the path π.
  • The first method MA is described in details below.
  • In the following, in the not limited embodiment described, the first method MA comprises the further steps and sub-steps above-mentioned.
  • Reference to the Figs. 1, 2 and 3 will be made.
  • For the following detailed description, in a not limited example given, a set of words W (associated to the built path π which is to be checked) is composed of two words ω1 and ω2 as following.
  • W = {ω1 = (m, moe, eom, mde, edm, m) ; ω2= (m, moe, eom, mde, m)}
  • In an initialization step 0), as illustrated in Fig. 3, one initializes a first and a second counters i and j to zero for counting respectively the number of words ω(π) forming the set of words W associated to the built path π, and the number of labels 1(π) within the set of words W.
  • As illustrated in Fig. 3, the first method MA starts from the initial state α and takes as an input the set of words W.
  • In a first step 1), as illustrated in Fig. 3, one launches a push-down automaton AUT for reading a word ω(π) associated to the built path π, a word ω(π) comprising labels 1(π) of an alphabet Σrepresenting technologies tck and adaptation functions supported by edges and/or nodes of the network system NTW, a label 1(π) of a word ω(π) being associated to an edge E or a node N of the built path π.
  • In the not limited example given, one reads the first word ω1 (i=0).
  • The push-down automaton AUT is described below.
  • Push-down automaton AUT
  • A schematic diagram of a not limited embodiment of the push-down automaton AUT is illustrated in Fig. 2.
  • Such a push-down automaton AUT comprises:
    • a stack STK and associated stack commands Φ ;
    • the alphabet Σof labels 1(π) representing technologies and adaptation functions supported by edges E and/or nodes N of the network system NTW ;
    • states st and transitions tr which labels 1(π) of the alphabet Σare associated to.
  • It also comprises an initial state α.
  • It is to be noted that the set of stack commands is named Φ and a stack command is named Cd.
  • In a not limited embodiment, the following stack commands Φ are associated to the stack STK:
    • MOE which fills in the stack STK with a "moe" label ;
    • EOM which fills in the stack STK with a "eom" label ;
    • MDE which fills in the stack STK with a "mde" label ;
    • EDM which fills in the stack STK with a "mde" label ;
    • MOE which removes a "moe" label from the stack STK ;
    • EOM which removes a "eom" label from the stack STK.
  • In a not limited embodiment, each state st but the initial state α is labeled with a label 1(π) representing a technology tck used within a node and/or an edge of the network system NTW. In the not limited example taken, the technology tck used is the protocol supported by a node and/or an edge, here MPLS of Ethernet.
  • Hence, the push-automaton AUT may be noted as AUT = {S, STK, Σ, Φ, α , TR, T), where:
    • S is the set of states, S={α, "e", "m"};
    • Σ={m,e,meo,eom,edm,mde};
    • Φ the stack commands, Φ={MOE, EOM, MDE, EDM, MOE , EOM };
    • TR is the set of transitions tr between the states; and
    • T={"e","m"} the terminal states.
  • In order to read a word ω(π) the push-down automaton AUT is able to, as illustrated in Fig. 3:
    • read a label 1(π) forming said word ω(π) (step 1 a: RD_L(1(π)j) ;
    • check if there is a transition tr associated to the label read 1(π) (step 1b:CHK_TR(l(π)j)) ;
    • if an associated transition tr exists (step 1 b:OK):
      • activate stack commands Φ on the stack STK according to the conditions Cond associated to the transition tr (step 1c: ACTIV_Cd(Cond)) ;
      • go to the egress state st* of the transition tr (step 1 d:GO_ST(TR(l(π)j))) ; and
      • iterate the preceding steps with the next label 1(π) of the word ω(π) (step 1e).
  • These sub-steps are described in detail below.
  • In a first sub-step 1a), as illustrated in Fig.3, one reads a label 1(π) forming said word ω(π)
  • In the not limited example given, one reads the first label "m" of the word ω1 (j=0).
  • In a second sub-step 1b), as illustrated in Fig. 3, one checks if there is a transition tr associated to the label read I(π).
  • In the not limited example given, there is one transition tr1 associated to the first label read "m" as illustrated in Fig. 2.
  • In a third sub-step 1c), as illustrated in Fig. 3, one activates stack commands Φ on the stack STK according to the conditions read Cond.
  • It is to be noted that for the initial state α, no stack commands Cd are associated. Therefore, no stack command Cd is activated.
  • It is to be noted that activating stack commands leads to fill in the stack STK with a label 1(π) or to remove from the stack STK a label I(π), as described hereinafter.
  • It is to be noted that the conditions Cond will be explained later in the description.
  • In a fourth sub-step 1d), as illustrated in Fig. 3, one goes to the egress state st* of the transition tr.
  • In the not limited example given, one goes to the egress state st1 * ="m" as illustrated in Fig. 2.
  • In a fifth sub-step 1e), one iterates the preceding sub-steps 1a) to 1d) with the next label 1(π) of the word ω(π)
  • In practical, the second counter j is increased by one.
  • In the not limited example given, the next label 1(π) of the word ω1 is "moe" (j=1).
  • In the not limited example given, for this label "moe":
    • there is one transition tr3 associated as illustrated in Fig. 3 (sub-step 1 b) ;
    • a first condition Cond1 is associated to the transition tr3. This condition is that the label 1(π) labeling the transition tr3 is representative of an encapsulated adaptation function moe. Therefore, one activates a push command MOE which fills in the stack STK with the label "moe" (sub-step 1 c) ; and
    • one goes to the egress state st2*="e" of the transition tr3 (sub-step 1 d).
  • The following table summarizes for the first word ω1 the different labels read l(π), the associated egress state st*, the state of the stack STK, the associated stack commands Φ activated.
    ω1 = (m, moe, eom, mde, edm, m)
    l(π) read = "m"; st1 *="m"; STK= {Ø}
    l(π) read = "moe"; st2*="e"; Cd=MOE; STK= {moe}
    l(π) read = "eom"; st1*="m"; Cd=EOM; STK= {eom,moe}
    l(π) read = "mde"; st1*="e"; Cd=EOM ;STK= {moe}
    l(π) read = "edm"; st1 *="m"; Cd= MOE; STK= {Ø}
    l(π) read = "m"; st1 *="m"; Cd=Ø; STK= {Ø}
  • Hence, once the first word ω1 is read by the push-automaton AUT, the stack STK is empty for the first word ω1.
  • When all the labels 1(π) of the first word ω1 have been proceeded by the push-down automaton AUT (when a corresponding transition tr exists as explained in step 1 b) (step 1f:OK; j=5<NBL=6), in a second step 2), one validates the built path π according to the result of the reading of said word ω1 and to the associated state of a stack STK of said push-automaton AUT, said stack STK being modified during the reading of the word ω(π) as described above.
  • The validation comprises the following sub-steps.
  • In a first sub-step 2a:OK), when a word ω(π) has been read entirely and the another node Nl is different from the destination node ND, one validates the path π being built with the adaptation functions corresponding to the word read ω(π).
  • It is to be noted that this sub-step is performed when the path π is being built, i.e. when it is an intermediate path, as the another node Nl is different from the destination node ND.
  • In a second sub-step 2a:NOK), when the word ω(π) has been read entirely and the another node Nl is equal to the destination node ND, the following sub-steps are performed.
  • It is to be noted that this sub-step is performed when the path π is a final path.
    • If the source node NS and the destination node ND are of homogeneous technologies tck (sub-step 2b:OK) and if the stack STK is empty (sub-step 2c:OK), one validates the path π with the adaptation functions corresponding to the word read ω(π) (sub-step 2e).
    • If the source node NS and the destination node ND are of heterogeneous technologies tck (sub-step 2b:NOK) and if the stack STK comprises a label representative of an adaptation function xoy, xdy (sub-step 2d:OK), one validates the path π with the adaptation functions corresponding to the word read ω(π) (sub-step 2e).
  • Hence, in the not limited example given of the word ω1 :
    • a) If the built path π is an intermediate path.
  • The first word ω1 has been read entirely. Therefore the built path π is validated with the adaptation functions corresponding to this word, that is to say, with the adaptation functions moe, eom, mde, edm. In this case, both nodes NS and ND could communicate using their corresponding protocols.
    • b) If the built path π is a final path.
  • The first word ω1 has been read entirely.
    • o If the source node NS and the destination node ND are of homogeneous technologies, for example MPLS, as the stack STK is empty for the first word ω1, one validates the built path π with the first word ω1 only, and therefore with the corresponding adaptation functions moe, eom, mde, edm. In this case, both nodes NS and ND could communicate using their corresponding protocols.
    • o If the source node NS and the destination node ND are of heterogeneous technologies, for example MPLS and Ethernet respectively, as the stack STK is empty for the first word ω1, no validation of the built path π is performed with the first word ω1.
  • in a third step 3), one iterates the preceding steps 1 and 2 with said next word ω(π) of the set of words W, i.e. the second word ω2.
  • In practical, the first counter i is increased by one (i=1) and the second counter j is reinitialized to zero. Moreover, one starts from the initial state α.
  • The following table summarizes for the second word ω2 the different labels read 1(π), the associated egress state st*, the state of the stack STK, the associated stack commands Φ activated.
    ω2= (m, moe, eom, mde, m)
    l(π) read = "m"; st1 *="m"; STK= {Ø}
    l(π) read = "moe"; st2*="e"; Cd=MOE; STK= {moe}
    l(π) read = "eom"; st1*="m"; Cd=EOM; STK= {eom,moe}
    l(π) read = "mde"; st1*="e"; Cd=EOM ; STK= {moe}
    l(π) read = "m"; st1 *="m"; Cd=Ø; STK= {moe}
  • Hence, once the second word ω2 is read by the push-automaton AUT, the stack STK is not empty for the second word ω2 but is fill in with the label moe.
  • When all the labels 1(π) of the second word ω2 have been proceeded by the push-down automaton AUT (when a corresponding transition tr exists as explained in step 1 b) (step 1 f:OK; j=4<NBL=5), in a second step 2), one validates the built path π according to the results of the reading of said word ω2 and to the associated state of the stack STK.
  • The validation comprises the following sub-steps.
  • Hence, in the not limited example given of the word ω2:
    • a) If the built path ω is an intermediate path.
  • The second word ω2 has been read entirely. Therefore the built path π is validated with the adaptation functions corresponding to this word, that is to say, with the adaptation functions moe, eom, mde.
    • b) If the built path π is a final path.
  • The second word ω2 have been read entirely.
    • o If the source node NS and the destination node ND are of homogeneous technologies, for example MPLS, as the stack STK is not empty for the second word ω2, no validation of the built path π is performed with the second word ω2.
    • o If the source node NS and the destination node ND are of heterogeneous technologies, for example MPLS and Ethernet respectively, as the stack STK is filled in with the encapsulated adaptation function "moe" for the second word ω2, one validates the built path π with the second word ω2, and therefore with the corresponding adaptation functions moe, eom, mde.
  • It is to be noted that in a not limited embodiment, if there is no associated transition tr associated to the label read 1(π) of a word ω(π) , one reiterates the preceding steps with the next word ω(π) of the set of words W (as illustrated in Fig. 3 : step 3). Thus, one stops the reading of the current word ω(π) and one goes to the next word ω(π)
  • It is to be noted that in a not limited embodiment, if there is no associated transition tr associated to the label read 1(π) of a word ω(π), one iterates the preceding steps with the next word ω(π) of the set of words W (as illustrated in Fig. 3 : step 3). Thus, one stops the reading of the current word ω(π) and one goes to the next word ω(π).
  • It is to be noted that a built path π is validated, that means is feasible, when at least a word ω(π) of the set of word W is "validated" according to the conditions above-described.
  • And, a built path π is invalidated, that means is not feasible, when all the words ω(π) of the set of words W associated to said path are "invalidated" according to the conditions above-described. This means when the built path π has been validated by none of the word ω(π) of a set of words W.
  • In other words, a word is invalidated (step INVALlD_W(ω(π))) when:
    • The source node NS and the destination node ND are of homogeneous technologies tck (sub-step 2b:OK) but the stack STK is not empty (sub-step 2c:NOK) ; or
    • If the source node NS and the destination node ND are of heterogeneous technologies tck (sub-step 2b:NOK) but the stack STK is empty (sub-step 2d:NOK).
  • It is to be noted that in a first not limited above-described, the validation of a built path π is performed each time a word ω(π) of the set of words W has been proceeded by the push-automaton AUT.
  • In a second not limited embodiment, the validation of a built path π is performed after all the words ω(π) of the set of words W have been proceeded by the push-automaton AUT. In this case, all the words read (entirely or not) are saved in a memory waiting for the step 2) to be performed. The same applied for the state of the stack STK associated to each word read ω(π).
  • In a not limited variant of the first and second embodiment, the step 2) of validation returns the number NBW of words ω(π) of the set of words W which have validated the path π, words which may be also called words validated. It permits to acquire a quality factor.
  • For example, the number NBW=2 for the case a) above-mentioned, as the two words ω1 and ω2 have been validated for the validation of the built path, and the number NBW=1 for the case b) above-mentioned, as there is only one word which has been validated for the validation of the built path (either ω1 or ω2).
  • Therefore, the first method MA permits to check the adaptation functions of a built path π and to validate said path π, either for an intermediate path, or for a final path and this thanks to the push-down automaton AUT.
  • Building of the push-down automaton AUT
  • It is to be noted that push-down automaton AUT described is built by a method MC for building a push-down automaton AUT for reading a word ω(π) associated to the built path π, a word ω(π) comprising labels 1(π) of an alphabet Σrepresenting technologies tck and adaptation functions supported by edges and/or nodes of the network system NTW, a label 1(π) of a word ω(π) being associated to an edge E or a node N of the built path π, said push-down automaton AUT comprising :
    • a stack STK and associated stack commandsΦ;
    • the alphabet Σof labels 1(π) representing technologies and adaptation functions supported by edges and/or nodes of the network system NTW ;
    • states st and transitions tr which labels 1(π) of the alphabet Σare associated to.
  • In the following description, said method for building a push-down automaton will also be called second method.
  • Said second method MC is illustrated in a not limited embodiment in Fig. 4. It comprises the steps of:
    • building stack commands Φ, (step BILD_STCKCd) where :
      • when a label 1(π) of an alphabet Σis representative of an encapsulation adaptation function xoy, build a push command XOY which is able to fill in a stack STK with said label 1(π) (step 1a:BILD_XOY) ;
      • when a label 1(π) of an alphabet Σis representative of a desencapsulation adaptation function xdy, build a remove command YOX which is able to remove the inverse label 1(π) from the stack STK and build a push command which is able to fill in the stack STK with said label 1(π) (step 1b:BILD_ YOX XDY) ;
    • building states st of the push-down automaton AUT (step BILD_ST), where :
      • when a label 1(π) of an alphabet Σis representative of a technology tck used within a node and/or an edge, build a state st which is named with said label 1(π) ;
    • building transitions tr of the push-down automaton AUT (step BILD_TR), where :
      • for each label 1(π) of an alphabet Σrepresentative of an adaptation function xoy, xdy, build a transition tr having as start state sts the first letter of said label 1(π), and having as end state ste the last letter of said label 1(π), and labeled said transition tr with said label 1(π) (step 3a:BILD_TR(sts=x; ste=y; l(π))) ,
      • for each label 1(π) of an alphabet Σrepresentative of a technology used tck within a node and/or an edge, build a reflexive transition tr over its corresponding state st, and labeled said transition tr with said label 1(π) (step 3b:BILD_TR(1(π))) ;
    • associating stack commands Φ to said transitions tr built according to conditions Cond (step 4:BILD_COND_CD(TR), where :
      • when the label 1(π) labeling a transition tr is representative of an encapsulated adaptation function xoy, the corresponding stack command Cd is associated to the transition tr (step 4a) ;
      • when the label 1(π) labeling a transition tr is representative of a desencapsulation adaptation function xdy and if the top entry of the stack STK is filled in with the inverse adaptation function yox, the corresponding remove command YOX is associated to the transition tr (step 4bi), otherwise the corresponding push command XDY is associated to the transition tr (step 4bii).
  • In a not limited embodiment, a label 1(π) of an alphabet Σ representative of an adaptation function is composed of three letters xoy, xdy, the first and third letters representing the technologies tck supported by the adaptation function, and the second letter (o or d) representing a type TY of the adaptation function.
  • In a not limited embodiment, a label 1(π) of an alphabet Σ representative of a technology tck used within a node and/or an edge is composed of a single letter.
  • Hence, in the example above given:
  • The label 1(π) of an alphabet Σrepresentative of an adaptation function MPLS over Ethernet is composed of three letters moe, the first and third letters, respectively m and e, representing the technologies tck supported by the adaptation function, respectively MPLS and Ethernet, and the second letter representing a type TY of the adaptation function, i.e. here "o" for the encapsulation.
  • The same applied for the adaptation function Ethernet over MPLS which label is eom.
  • In the same manner, the label 1(π) of an alphabet Σrepresentative of the inverse adaptation function of eom : MPLS from Ethernet is composed of three letters mde, the first and third letters, respectively m and e, representing the technologies tck supported by the adaptation function, respectively MPLS and Ethernet, and the second letter representing a type TY of the adaptation function, i.e. here "d" for desencapsulation.
  • The same applied for the inverse adaptation function of moe which label is edm.
  • The second method MC is described in details hereinafter.
  • The same example taken for the first method MA and illustrated in Fig.2. is taken as a not limited example. Thus, reference to Fig. 2 and Fig. 4 will be made.
  • In a first step 1), one builds stack commands Φ as following.
    • When a label 1(π) of an alphabet Σis representative of an encapsulation adaptation function moe, eom, one builds a push command respectively MOE, EOM which is able to fill in the stack STK with said label 1(π) moe, eom respectively.
    • When a label 1(π) of an alphabet Σis representative of a desencapsulation adaptation function mde, edm, one builds a remove command EOM , MOE which is able to remove the inverse label 1(π), respectively eom, moe, from the stack STK, and one builds a push command MDE, EDM which is able to fill in the stack STK with said label mde, edm respectively.
  • In a second step 2), one builds states st of the push-down automaton AUT as following.
  • When a label 1(π) of an alphabet Σis a single letter representative of a technology tck used within a node and/or an edge, in the example e or m, one builds a state, respectively st1 * and st2*, which is named with said label e or m.
  • In a third step 3), one builds transitions tr of the push-down automaton AUT as following.
  • Hence, as illustrated in Fig. 2, for the label moe representative of the MPLS over Ethernet adaptation function, one builds the transition tr3 having the start state sts=st1*= "m" and as end state ste=st2*="e", and labeled said transition tr3=moe.
  • For the label eom representative of the Ethernet over MPLS adaptation function, one builds the transition tr4 having the start state sts=st2*= "e" and as end state ste=st1 *="m", and labeled said transition tr4=eom.
  • For the label "mde" representative of the inverse adaptation function of eom, one builds the transition tr6 having the start state sts=st1*= "m" and as end state ste=st2*="e", and labeled said transition tr6=mde.
  • For the label edm representative of the inverse adaptation function of moe, one builds the transition tr5 having the start state sts=st2*= "e" and as end state ste=st1 *="m", and labeled said transition tr5=edm.
  • Finally, as illustrated in Fig. 2, for the label m representative of the MPLS technology used within a node and/or an edge, one builds a reflexive transition tr2 over its corresponding state st1*, and labeled said transition tr2 with said label m.
  • And for the label e representative of the Ethernet technology used within a node and/or an edge, one builds a reflexive transition tr7 over its corresponding state st2*, and labeled said transition tr7 with said label e.
  • In a fourth step 4), one associates stack commands Φ to said transitions tr built according to conditions Cond as following.
  • In a not limited embodiment, two conditions Cond1 and Cond2 are used.
  • Regarding the first condition Cond1: when the label 1(π) labeling a transition tr is representative of an encapsulated adaptation function xoy, the corresponding stack command XOY is associated to the transition tr.
  • Hence, for the label moe, the stack command MOE is associated to the transition tr3.
  • For the label eom, the stack command EOM is associated to the transition tr4.
  • Regarding the second condition Cond2: when the label 1(π) labeling a transition tr is representative of a desencapsulation adaptation function xdy and if the top entry of the stack STK is filled in with the inverse adaptation function yox, the corresponding remove command YOX is associated to the transition tr, otherwise the corresponding push command XDY is associated to the transition tr.
  • Hence, for the label mde, if the top entry of the stack STK is eom, the remove command EOM is associated to the transition tr6, otherwise the push command MDE is associated.
  • For the label edm, if the top entry of the stack STK is moe, the remove command MOE is associated to the transition tr5, otherwise the push command EDM is associated.
  • It is to be noted that these conditions Cond are part of the push-automaton AUT as the stack STK, the stack commands Φ, the transitions tr, the states st etc. as described before.
  • The method MA for checking a path and the method MC for building a push-down automaton above-described are carried out by a network management element NME of a system NTW.
  • As illustrated on Fig. 5, in the not limited schematic example given, said network system NTW is a multi-domain network and is able to manage:
    • a source domain D1;
    • a plurality of intermediate domains Dy;
    • a destination domain D2;
    each comprising a plurality of nodes N and edges E and one network management element NMEs, NMEy, and NMEd respectively. Of course, other architectures may be taken as examples where a domain D comprises a plurality of network management elements NME.
  • In order to simplify the Fig. 5, it is to be noted that not all the edges E and the nodes N have been referenced in the Fig. 5.
  • In this example, the network system NTW is able to manage:
    • a source network management element NMEs which is within the source domain D1 comprising the source node NS ;
    • intermediate network management elements NMEy which are within intermediate domains Dy between the source domain D1 and a destination domain D2, said intermediate domains Dy comprising intermediate nodes Nl which are between the source node NS and the destination node ND ; and
    • the destination network management element NMEd which is within the destination domain D2 comprising the destination node ND.
  • It is to be noted that in a not limited embodiment, a domain is a collection of network management elements NME within a common sphere of address management or computational responsibility as defined in the IETF standard. In not limited examples, a domain may be an Autonomous System (AS), an interior gateway protocol IGP routing area, or a Generalized Multiprotocol Label Switching overlay network layer.
  • It is to be noted that:
    • An autonomous system AS usually refers to a group of routers within a network that are subject to a common authority and use the same intra-domain routing protocol.
    • An area usually refers to a collection of routers that share full network topology information with each other but not necessarily with routers outside the area even those with which they share common administrative control.
  • It is to be noted that a network management element NME is aware of:
    • the topology of its own domain D, that is to say of how the nodes of said domain D are arranged physically altogether within said domain D, and how they communicate with one another, and what are the Traffic Engineering capabilities (e.g. maximal bandwidth, transmission delay, etc.) on their links;
    • the neighbor domains Dn of its own domain D; and
    • the border nodes of the neighbor domains Dn;
    • the network management elements NME of its neighbor domains.
  • To this end, a network management element uses a database.
  • In not limited examples, a network management element NME is:
    • a Network Management System, NMS ;
    • a Path Computation Element, PCE as per specified in the document RFC4555 ― A Path Computation Element (PCE) ― based Architecture ― August 2006. In this case the database aforementioned is called traffic Engineering Database (TED) ;
    • a router ;
    • an Operational Support System, OSS;
    • an administrative owner AO.
  • It is to be noted that the nodes N described in a not limited example are routers. Thus, when a router NS of the domain D1 (called the source node or here a source router) wants to transmit some data to router ND of another domain D2 (called a destination node or here a destination router), it delivers a service to the destination router ND. The first method MA is thus start up by a source network management element NMEs within the source domain D1, intermediate network management elements NMEy within intermediate domain Dy, and the destination network management element NMEd within the destination domain D2.
  • The source, intermediate and destination network management elements NME are described hereinafter according to Fig. 6.
  • It is to be noted that in Fig. 6, in view of efficiency, only the source network management element NMEs has been illustrated in detailed. The same description is to be applied to the intermediate and destination network management elements NMEy and NMEd.
  • As illustrated in Fig. 6, a network management element NME for checking a path π built between a source node NS and another node Nl for a network system NTW, according to adaptation functions, said network management element NME comprises the push-down automaton AUT.
  • As illustrated in Fig. 6, a network management element NMEs for checking a path π built between a source node NS and another node Nl for a network system NTW, according to adaptation functions, is able to carry out the method MA for checking a path.
  • In a not limited embodiment, said network management element NMEs comprises in particular a control unit UC which is able to:
    • launch a push-down automaton AUT for reading a word ω(π) associated to the built path π, a word ω(π) comprising labels 1(π) of an alphabet Σrepresenting technologies tck and adaptation functions supported by edges and/or nodes of the network system NTW, a label 1(π) of a word ω(π) being associated to an edge or a node of the built path π ; and
    • validating the built path π according to the result of the reading of the word ω(π) and to the state of a stack STK of said push-automaton AUT, said stack STK being modified during the reading of the word ω(π).
  • In not limited embodiments, the control unit UC is further able to perform the corresponding sub-steps of the validation as described before.
  • As further illustrated in Fig. 6, a network management element NMEs for checking a path π built between a source node NS and another node Nl for a network system NTW, according to adaptation functions, is able to carry out the method MC for building a push-down automaton.
  • In a not limited embodiment, said network management element NMEs comprises in particular a control unit UC which is able to:
    • build stack commands Φ, where :
      • when a label 1(π) of an alphabet Σis representative of an encapsulation adaptation function xoy, build a push command XOY which is able to fill in a stack STK with said label 1(π) ;
      • when a label 1(π) of an alphabet Σis representative of a desencapsulation adaptation function xdy, build a remove command YOX which is able to remove the inverse label 1(π) from the stack STK and build a push command XDY which fill in the stack STK with said label xdy ;
    • build states st of the push-down automaton AUT, where :
      • when a label 1(π) of an alphabet Σis representative of a technology tck used within a node and/or an edge, build a state st which is named with said label 1(π) ;
    • build transitions tr of the push-down automaton AUT (step BILD_TR), where :
      • for each label 1(π) of an alphabet Σrepresentative of an adaptation function xoy, xdy, build a transition tr having as start state sts the first letter of said label 1(π), and having as end state ste the last letter of said label 1(π), and labeled said transition tr with said label 1(π) ;
      • for each label 1(π) of an alphabet Σrepresentative of a technology used tck within a node and/or an edge, build a reflexive transition tr over its corresponding state st, and labeled said transition tr with said label 1(π) ;
    • associate stack commands Φ to said transitions tr built according to conditions Cond, where :
      • when the label 1(π) labeling a transition tr is representative of an encapsulated adaptation function xoy, the corresponding stack command Cd is associated to the transition tr ;
      • when the label 1(π) labeling a transition tr is representative of a desencapsulation adaptation function xdy and if the top entry of the stack STK is filled in with the inverse adaptation function yox, the corresponding remove command YOX is associated to the transition tr, otherwise the corresponding push command XDY is associated to the transition tr.
  • It is to be understood that the present invention is not limited to the aforementioned embodiments and variations and modifications may be made without departing from the scope of the invention. In the respect, the following remarks are made.
  • It is to be understood that the present invention is not limited to the aforementioned application.
  • Hence, the first method MA may be used for inter-domain path computation such as in not limited examples:
    • Intra-carrier case:
      • in optics, when an operator network is split in multiple domains with each domain gathering transport equipments from one operator for example.
      • in IP/MPLS (Internet Protocol/Multiprotocol Label Switching), when an operator network is divided into multiple domains (i.e. IGP areas) for scalability purpose.
    • Inter-carrier case: where each operator NME is likely to know about its neighbor network management element NME.
  • It is to be noted that the not limited example of a multi-domain network system (inter-domain or intra-domain) comprising a plurality of network management elements NME has been given, but of course the invention also applies to network system without any domains.
  • It is to be understood that the present invention is not limited to the aforementioned embodiments.
  • Hence, in not limited examples, other adaptation functions may be used, based on other technologies, such as in not limited examples IP or the Synchronous Digital Hierarchy protocol SDH.
  • Thus, the other adaptation functions may be:
    • MPLS over IP
    • IP over MPLS
    • Ethernet over IP ;
    • IP over Ethernet;
    • Synchronous Digital Hierarchy (SDH) over Ethernet ;
    • Ethernet over SDH;
    the corresponding desencapsulation adaptation functions :
    • IP from MPLS ;
    • MPLS from IP ;
    • IP from Ethernet ;
    • Ethernet from IP ;
    • MPLS from Ethernet ;
    • Ethernet from MPLS ;
    • Ethernet from SDH ;
    • SDH over Ethernet.
  • It is to be understood that the methods and the elements according to the invention are not limited to any implementation.
  • There are numerous ways of implementing functions of the first method MA and of the second method MC by means of items of hardware or software, or both, provided that a single item of hardware or software can carry out several functions. It does not exclude that an assembly of items of hardware or software or both carry out a function. For example, the step of building stack commands may be combined with the step of building states of the push down automaton, thus forming a single function without modifying the building method MC in accordance with the invention.
  • Said hardware or software items can be implemented in several manners, such as by means of wired electronic circuits or by means of a computer program product that is suitable programmed respectively. A first computer program product PG1 can be contained in a computer or in a network management element NME and in the same manner, a second computer program product PG2 can be contained in a computer or in a network management element NME, said NME comprising a unit control as described previously, said unit control being hardware or software items as above stated.
  • The first computer program product PG1 comprises a first set of instructions. Thus, said first set of instructions contained, for example, in a computer programming memory or in a network management element memory NME, may cause the computer or the network management element NME to carry out the different steps of the method MA for checking a path (and thus the different steps of the push-down automaton AUT).
  • The second computer program product PG2 comprises a second set of instructions.
  • Thus, said second set of instructions contained, for example, in a computer programming memory or in a network management element memory NME memory, may cause the computer or the network management element memory NME to carry out the different steps of the method MC for building a push-down automaton.
  • The different sets of instructions may be loaded into the programming memory by reading a data carrier such as, for example, a disk. A service provider can also make the set of instructions available via a communication network such as, for example, the Internet.
  • In another limited embodiment, a third computer program product (not illustrated) can be contained in a computer or in a network management element NME, said third computer program product comprising a third set of instructions. Said third set of instructions contained, for example, in a computer programming memory or in a network management element memory NME, may cause the computer or the network management element NME to carry out the different steps of the push automaton AUT.
  • In another not limited embodiment, the push automaton AUT comprises a unit control which is able to read a label, check if there is a transition, activate stack commands etc. as described before, said unit control being hardware or software items as above stated. In this embodiment, the third computer program product (not illustrated) can be contained in a computer or in the push-down automaton.
  • Hence, some embodiments of the invention may comprise one or a plurality of the following advantages:
    • it avoids leading to unfeasible paths as the cited prior art;
    • it permits to have a complete automatic procedure to check the feasibility of a path built between two nodes according to adaptation functions;
    • it permits to check the final path built between a source node and a destination node, but also an intermediate path built between a source node and an intermediate node ;
    • it is simple to implement ;
    • it permits to find a feasible path that allows multiple encapsulation/desencapsulation in an efficient manner ;
    • it permits to find a feasible path subject to traffic engineering constraints such as adaptiveness constraint based on adaptation functions ;
    • it permits to give a solution which may be deployed within a service layer architecture to allow inter-carrier service ;
    • it permits to give a solution which may be used in general in any algorithms which builds a path between two nodes. These algorithms may be in not limited examples, an ant algorithm, a genetic algorithm, a dijkstra algorithm, a bellman-ford algorithm, a dynamic programming algorithm ;
    • the first method may be dynamically set up and thus the push-down automaton may evolve in the same time as the alphabet evolves ;
    • it has a runtime performance linear to the alphabet and word sizes, which better than a runtime performance exponential or polynomial ; and
    • it could be used with any alphabet representing functions similar to encapsulation/desencapsulation adaptation functions such as in not limited examples encryption/decryption functions.
  • Any reference sign in the following claims should not be construed as limiting the claim. It will be obvious that the verb "to comprise" and its conjugations do not exclude the presence of any other steps or elements beside those defined in any claim. The word "a" or "an" preceding an element or step does not exclude the presence of a plurality of such elements or steps.

Claims (18)

  1. A method (MA) for checking a path (π) built between a source node (NS) and another node (Nl) for a network system (NTW), according to adaptation functions, said method comprising the steps of :
    - launching a push-down automaton (AUT) for reading a word ω(π)) associated to the built path (π), a word (ω(π)) comprising labels (1(π)) of an alphabet (Σ) representing technologies (tck) and adaptation functions supported by edges and/or nodes of the network system (NTW), a label (1(π)) of a word (ω(π)) being associated to an edge (E) or a node (N) of the built path (π) ; and
    - validating the built path (π) according to the result of the reading of the word (ω(π)) and to the state of a stack (STK) of said push-automaton (AUT), said stack (STK) being modified during the reading of the word (ω(π)).
  2. A method (MA) according to the previous claim 1, wherein a set of words (W) is read.
  3. A method (MA) according to the previous claim 1 or 2, wherein the validation of the built path (π) comprises the sub-step of :
    - when the word (ω(π)) has been read entirely and the another node (Nl) is different from a destination node (ND), validating the path (π) being built with the adaptation functions corresponding to the word read (ω(π)).
  4. A method (MA) according to the any one of the previous claims, wherein the validation of the built path (π) further comprises the sub-steps of :
    - when the word (ω(π)) has been read entirely and the another node (Nl) is equal to a destination node (ND) :
    - if the source node (NS) and the destination node (ND) are of homogeneous technologies (tck) and if the stack (STK) is empty, validating the path (π) with the adaptation functions corresponding to the word read (ω(π)) ;
    - if the source node (NS) and the destination node (ND) are of heterogeneous technologies (tck) and if the stack (STK) comprises a label representative of an adaptation function , validating the path (π) with the adaptation functions corresponding to the word read (ω(π)).
  5. A method (MA) according to the any one of the previous claims, wherein the push-down automaton (AUT) comprises :
    - a stack (STK) and associated stack commands (Φ) ;
    - the alphabet (Σ) of labels (1(π)) representing technologies (tck) and adaptation functions supported by edges and/or nodes of the network system (NTW) ;
    - states (st) and transitions (tr) which labels (1(π)) of the alphabet (Σ) are associated to;
    and is able to :
    - read a label (1(π)) forming said word (ω(π)) ;
    - check if there is a transition (tr) associated to the label read (1(π))
    - if an associated transition (tr) exists :
    - activate stack commands (Φ) on the stack (STK) according to conditions (Cond) associated to the transition (tr) ;
    - go to the egress state (st*) of the transition (tr) ; and
    - iterate the preceding steps with the next label (1(π)) of the word (ω(π)).
  6. A push-down automaton (AUT) able to read a word (ω(π)) associated to a built path (π), a word comprising labels (1(π)) of an alphabet (Σ) representing technologies (tck) and adaptation functions supported by edges and/or nodes of a network system (NTW), a label (1(π)) of a word (ω(π)) being associated to an edge (E) or a node (N) of the built path (π), said push-down automaton (AUT) comprising:
    - a stack (STK) and associated stack commands (Φ) ;
    - the alphabet (Σ) of labels (1(π)) representing technologies (tck) and adaptation functions supported by edges and/or nodes of the network system (NTW) ;
    - states (st) and transitions (tr) which labels (1(π)) of the alphabet (Σ) are associated to;
    said push-down automaton (AUT) being able to :
    - read a label (1(π)) forming said word (ω(π)) ;
    - check if there is a transition (tr) associated to the label read (1(π))
    - if an associated transition (tr) exists :
    - activate stack commands (Φ) on the stack (STK) according to conditions (Cond) associated to the transition (tr) ;
    - go to the egress state (st*) of the transition (tr) ; and
    - iterate the preceding steps with the next label (1(π)) of the word (ω(π)).
  7. A method (MC) for building a push-down automaton (AUT) for reading a word (ω(π)) associated to the built path (π), a word (ω(π)) comprising labels (1(π)) of an alphabet (Σ) representing technologies (tck) and adaptation functions supported by edges and/or nodes of a network system (NTW), a label (1(π)) of a word (ω(π)) being associated to an edge (E) or a node (N) of the built path (π), said push-down automaton (AUT) comprising :
    - a stack (STK) and associated stack commands (Φ) ;
    - the alphabet (Σ) of labels (1(π)) representing technologies and adaptation functions supported by edges and/or nodes of the network system (NTW) ;
    - states (st) and transitions (tr) which labels (1(π)) of the alphabet (Σ) are associated to;
    said method (MC) comprising the steps of :
    - building stack commands (Φ), where :
    - when a label (1(π)) of an alphabet (Σ) is representative of an encapsulation adaptation function (xoy), build a push command (XOY) which is able to fill in a stack (STK) with said label (1(π)) ;
    - when a label (1(π)) of an alphabet (Σ) is representative of a desencapsulation adaptation function (xdy), build a remove command ( YOX ) which is able to remove the inverse label (1(π)) from the stack (STK) and build a push command (XDY) which is able to fill in a stack with said label (1(π)) ;
    - building states (st) of the push-down automaton (AUT), where :
    - when a label (1(π)) of an alphabet (Σ) is representative of a technology (tck) used within a node and/or an edge, build a state (st) which is named with said label (1(π));
    - building transitions (tr) of the push-down automaton (AUT), where :
    - for each label (1(π)) of an alphabet (Σ) representative of an adaptation function (xoy, xdy), build a transition (tr) having as start state (sts) the first letter of said label (1(π)), and having as end state (ste) the last letter of said label (1(π)), and labeled said transition (tr) with said label (1(π));
    - for each label (1(π)) of an alphabet (Σ) representative of a technology used (tck) within a node and/or an edge, build a reflexive transition (tr) over its corresponding state (st), and labeled said transition (tr) with said label (1(π));
    - associating stack commands (Φ) to said transitions (tr) built according to conditions (Cond), where :
    - when the label (1(π)) labeling a transition (tr) is representative of an encapsulated adaptation function (xoy), the corresponding stack command (XOY) is associated to the transition (tr) ;
    - when the label (1(π)) labeling a transition (tr) is representative of a desencapsulation adaptation function (xdy) and if the top entry of the stack (STK) is filled in with the inverse adaptation function (yox), the corresponding remove command ( YOX ) is associated to the transition (tr), otherwise the corresponding push command (XDY) is associated to the transition (tr).
  8. A method (MC) according to the preceding claim, wherein a label (1(π) of an alphabet (Σ representative of an adaptation function is composed of three letters (xoy, xdy), the first and third letters representing the technologies (tck) supported by the adaptation function, and the second letter representing a type (TY) of the adaptation function.
  9. A method (MC) according to any one of the previous claims 7 or 8, wherein a label (1(π) of an alphabet (Σ representative of a technology (tck) used within a node and/or an edge is composed of a single letter.
  10. A method (MC) according to any one of the previous claims 7 to 9, wherein a technology (tck) is Ethernet, IP, Multiprotocol Label Switching (MPLS), or Synchronous Digital Hierarchy (SDH).
  11. A method (MC) according to any one of the previous claims 7 to 10, wherein an adaptation function is :
    - Multiprotocol Label Switching (MPLS) over IP ; or
    - IP over Multiprotocol Label Switching (MPLS) ; or
    - Ethernet over IP ; or
    - IP over Ethernet ; or
    - Multiprotocol Label Switching (MPLS) over Ethernet ; or
    - Ethernet over Multiprotocol Label Switching (MPLS) ; or
    - Synchronous Digital Hierarchy (SDH) over Ethernet ; or
    one of the corresponding desencapsulation adaptation functions.
  12. A network management element (NME) for checking a path (π built between a source node (NS) and another node (Nl) for a network system (NTW), according to adaptation functions, said network management element (NME) comprising the push-down automaton (AUT) according to the claim 6.
  13. A network management element (NME) for checking a path (π)built between a source node (NS) and another node (Nl) for a network system (NTW), according to adaptation functions, said network management element (NME) being able to carry out the method (MA) for checking a path according to any one of the previous claims 1 to 5.
  14. A network management element (NME) for checking a path (π) built between a source node (NS) and another node (Nl) for a network system (NTW), according to adaption functions, said network management element (NME) being able to carry out the method (MC) for building a push-down automaton (AUT) according to any one of the previous claims 7 to 11.
  15. A network management element (NME) according to any one of the previous claims 12 to 14, wherein the network management element (NME) is :
    - a network management system (NMS) ; or
    - a path computation element (PCE) ; or
    - a router ; or
    - an operational support system (OSS) ; or
    - an administrative owner (AO).
  16. A network system (NTW) for checking a path (π) built between a source node (NS) and another node (Nl) for a network system (NTW), according to adaptation functions, said network system being able to manage a network management element (NME) according to the any one of the previous claims 12 to 15.
  17. A computer program product (PG1) for a computer, comprising a set of instructions, which when loaded into said computer, causes the computer to carry out the method (MA) for checking a path according to any one of the claims 1 to 5.
  18. A computer program product (PG2) for a computer, comprising a set of instructions, which when loaded into said computer, causes the computer to carry out the method (MC) for building a push-down automaton (AUT) according to any one of the claims 7 to 11.
EP09177409A 2009-11-27 2009-11-27 A method for checking a path according to encapsulation functions using a push-down automaton Not-in-force EP2328300B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP09177409A EP2328300B1 (en) 2009-11-27 2009-11-27 A method for checking a path according to encapsulation functions using a push-down automaton

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP09177409A EP2328300B1 (en) 2009-11-27 2009-11-27 A method for checking a path according to encapsulation functions using a push-down automaton

Publications (2)

Publication Number Publication Date
EP2328300A1 true EP2328300A1 (en) 2011-06-01
EP2328300B1 EP2328300B1 (en) 2012-09-05

Family

ID=41507924

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09177409A Not-in-force EP2328300B1 (en) 2009-11-27 2009-11-27 A method for checking a path according to encapsulation functions using a push-down automaton

Country Status (1)

Country Link
EP (1) EP2328300B1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110276A1 (en) * 2001-12-10 2003-06-12 Guy Riddle Dynamic tunnel probing in a communications network
WO2009118050A1 (en) * 2008-03-28 2009-10-01 Telefonaktiebolaget Lm Ericsson (Publ) End-to-end inter-domain routing

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030110276A1 (en) * 2001-12-10 2003-06-12 Guy Riddle Dynamic tunnel probing in a communications network
WO2009118050A1 (en) * 2008-03-28 2009-10-01 Telefonaktiebolaget Lm Ericsson (Publ) End-to-end inter-domain routing

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BALIOSIAN J ET AL: "Finite state transducers for policy evaluation and conflict resolution", PROCEEDINGS. INTERNATIONAL WORKSHOP ON POLICIES FOR DISTRIBUTEDSYSTEMS AND NETWORKS, XX, XX, 7 June 2004 (2004-06-07), pages 1 - 10, XP002417638 *

Also Published As

Publication number Publication date
EP2328300B1 (en) 2012-09-05

Similar Documents

Publication Publication Date Title
EP2328308B1 (en) Method for building a path according to adaptation functions using an ant colony
CN111713079B (en) Packet network interworking including segment routing
CN101636973B (en) Method and device for dividing header stack of business unit
US20100063988A1 (en) Service Insertion in a Computer Network Using Internet Protocol Version 6 Techniques
CN112087386B (en) Message processing method, device and system
US11050662B2 (en) Malleable routing for data packets
US20070189291A1 (en) Source routed multicast LSP
US20100118732A1 (en) Loop prevention technique for mpls using service labels
CN108574634B (en) Apparatus, system, and method for providing node protection across label switched paths sharing labels
US8495245B2 (en) Connectivity, adjacencies and adaptation functions
EP3253012B1 (en) Method and apparatus for obtaining port path
US7161946B1 (en) Technique for multiprotocol transport using MPLS (multi-protocol label switching)
US9871675B2 (en) Interconnecting virtual private networks
US20160277279A1 (en) Link discovery method, system, and device
EP2597827B1 (en) Method of promoting a quick data flow of data packets in a communication network, communication network and data processing unit
US10069724B1 (en) System and method for verifying the functionality of network paths
US7319699B1 (en) Distributed imposition of multi-level label stack using local label
US9407544B1 (en) Network virtualization using IP map and encapsulation
WO2021073357A1 (en) Packet processing method, device, system and apparatus as well as storage medium
EP2369792B1 (en) Method for path determination according to adaptation functions
CN111226422B (en) Method for establishing a path in the optical domain and network node in a communication network
US11489768B2 (en) Method for creating inter-domain bidirectional tunnel, communication method and device, and storage medium
US20140078936A1 (en) Apparatus for configuring overlay network and method thereof
EP2328300B1 (en) A method for checking a path according to encapsulation functions using a push-down automaton
CN102624601A (en) Data message transmission method, network device and network system

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

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 HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

AX Request for extension of the european patent

Extension state: AL BA RS

17P Request for examination filed

Effective date: 20110513

17Q First examination report despatched

Effective date: 20110527

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

Owner name: ALCATEL LUCENT

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

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

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 574529

Country of ref document: AT

Kind code of ref document: T

Effective date: 20120915

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602009009428

Country of ref document: DE

Effective date: 20121031

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 574529

Country of ref document: AT

Kind code of ref document: T

Effective date: 20120905

REG Reference to a national code

Ref country code: NL

Ref legal event code: VDEP

Effective date: 20120905

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121205

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

Effective date: 20120905

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121206

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121216

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130105

Ref country code: BE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20130107

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

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

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20121205

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

26N No opposition filed

Effective date: 20130606

REG Reference to a national code

Ref country code: IE

Ref legal event code: MM4A

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602009009428

Country of ref document: DE

Effective date: 20130606

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20121127

REG Reference to a national code

Ref country code: FR

Ref legal event code: GC

Effective date: 20131018

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: MC

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20121130

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

Ref country code: LU

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20121127

REG Reference to a national code

Ref country code: CH

Ref legal event code: PL

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: CH

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131130

Ref country code: LI

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20131130

Ref country code: HU

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20091127

REG Reference to a national code

Ref country code: FR

Ref legal event code: RG

Effective date: 20141016

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20120905

REG Reference to a national code

Ref country code: FR

Ref legal event code: PLFP

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20151118

Year of fee payment: 7

Ref country code: DE

Payment date: 20151119

Year of fee payment: 7

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20151119

Year of fee payment: 7

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 602009009428

Country of ref document: DE

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20161127

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20170731

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20161130

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20170601

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20161127