WO2020021558A1 - Methods, apparatus and machine-readable media relating to path computation in a communication network - Google Patents

Methods, apparatus and machine-readable media relating to path computation in a communication network Download PDF

Info

Publication number
WO2020021558A1
WO2020021558A1 PCT/IN2018/050493 IN2018050493W WO2020021558A1 WO 2020021558 A1 WO2020021558 A1 WO 2020021558A1 IN 2018050493 W IN2018050493 W IN 2018050493W WO 2020021558 A1 WO2020021558 A1 WO 2020021558A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
mp2mp
p2mp
message
capability
Prior art date
Application number
PCT/IN2018/050493
Other languages
French (fr)
Inventor
Kotesh Babu CHUNDU
Gangadhara Reddy CHAVVA
Satish Kumar N RODD
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/IN2018/050493 priority Critical patent/WO2020021558A1/en
Publication of WO2020021558A1 publication Critical patent/WO2020021558A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/50Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]
    • H04L45/507Label distribution
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24Negotiation of communication capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/16Multipoint routing

Definitions

  • Embodiments of the present disclosure relate to path computation in a communication network, and particularly provide methods, apparatus and machine-readable media relating to computation of point-to-multipoint and multipoint-to-multipoint paths in a communication network.
  • Path computation is a well-known problem in communication networks, such as multi-protocol label switching (MPLS) networks.
  • Path computation elements use one or more of various algorithms to determine an appropriate path between a source and a destination. The algorithms may seek to minimize or maximize a particular metric, whether for the path itself or the network overall. For example, in the former category the determined path may be the shortest path (e.g., as defined by the number of hops) or the path associated with the lowest latency. In the latter category, the determined path may be the path that results in the greatest overall throughput in the network, or the most efficient usage of network resources (e.g., such that particular links or nodes of the network are not overloaded, etc). Algorithms in this category may be known as traffic-engineering algorithms.
  • P2P point-to-point
  • MP2MP Multipoint-to-multipoint
  • LSPs Label Switched Paths
  • SDN software-defined network
  • PCE performing the calculation may not be aware of the capabilities of the nodes and links along any proposed path to perform packet replication.
  • Some nodes may be incapable of performing the replication of data packets required if that node is to act as a branching point in the P2MP/MP2MP path.
  • some links e.g., line cards for a node such as a router
  • the PCE may instead replicate P2MP/MP2MP functionality using ingress replication, in which multiple separate paths are calculated from each source to each of the multiple destinations.
  • ingress replication ingress replication
  • a solution is therefore require which permits the calculation of a P2MP or MP2MP path.
  • An IETF request for comments introduces the possibility of using border gateway protocol (BGP) messages to transmit link state and traffic engineering information, collected from networks, to external components like SDN controllers using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format.
  • BGP border gateway protocol
  • NLRI BGP Network Layer Reachability Information
  • BGP is a distance-vector protocol, in which nodes advertise the routes to their respective known destinations.
  • BGP link state extensions share topology information such as node, link and prefix information. Once this information is propagated to the external component through a BGP link state session, the external component is able to realize the logical topology of the network and can program label- switched paths based on the configured policies.
  • Embodiments of the present disclosure seek to advertise the P2MP and/or MP2MP capabilities of nodes and links within a network, so as to enable PCEs and SDN controllers to calculate paths for P2MP/MP2MP data flows through that network.
  • the P2MP/MP2MP capabilities are advertised using BGP link state messages or packets.
  • a method performed by a route server of an area in a communication network comprises: receiving a first message from a node of the area in the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations; and transmitting a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
  • Another aspect provides a method in a controller node for a communication network.
  • the communication network comprises one or more areas.
  • the controller node is configured to perform path computation for the communication network.
  • the method comprises: receiving a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receiving a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determining a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiating establishment of a tunnel between the source node and the destination node according to the determined path.
  • a further aspect provides a route server for an area in a communication network.
  • the route server comprises processing circuitry and a machine-readable medium storing instructions which, when executed by the processing circuitry, cause the route server to: receive a first message from a node of the area of the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point- to-multi-point, P2MP, or multi-point- to-multi-point, MP2MP, operations; and transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
  • the communication network comprises one or more areas.
  • the controller node is configured to perform path computation for the communication network.
  • the controller node comprises processing circuitry and a machine -readable medium storing instructions which, when executed by the processing circuitry, cause the controller node to: receive a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network;
  • a further aspect provides a machine-readable medium storing instructions which, when executed by processing circuitry of a route server for an area in a communication network, cause the route server to: receive a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point- to-multi-point, P2MP, or multi-point- to-multi-point, MP2MP, operations; and transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
  • a yet further aspect of the disclosure provides a machine-readable medium storing instructions which, when executed by processing circuitry of a controller node for a communication network, the communication network comprising one or more areas, the controller node configured to perform path computation for the communication network, cause the controller node to: receive a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiate establishment of a tunnel between the source node and the destination node according to the determined path.
  • Figure 1 illustrates a communication network according to embodiments of the disclosure
  • Figure 2 is a flow chart of a method in a route server according to embodiments of the disclosure
  • Figure 3 shows a type-length-value (TLV) format for an attribute of a second message according to embodiments of the disclosure
  • Figure 4 is a flow chart of a method in a controller node according to embodiments of the disclosure.
  • Figure 5 is a schematic diagram of a route server according to embodiments of the disclosure
  • Figure 6 is a schematic diagram of a route server according to further embodiments of the disclosure
  • Figure 7 is a schematic diagram of a controller node according to embodiments of the disclosure.
  • Figure 8 is a schematic diagram of a controller node according to further embodiments of the disclosure.
  • Nodes that communicate using the air interface also have suitable radio communications circuitry.
  • the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
  • Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a computer is generally understood to comprise one or more processors, one or more processing modules or one or more controllers, and the terms computer, processor, processing module and controller may be employed interchangeably.
  • the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed.
  • the term“processor” or“controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
  • Figure 1 shows a communication network 100 according to embodiments of the disclosure.
  • the network 100 may implement one or more protocols for transmitting data packets from one node (e.g., an ingress node) to another node (e.g., an egress node) along a defined path.
  • the network 100 implements multiprotocol label switching (MPLS), in which label- switched paths are utilized to define the paths along which packets are transmitted.
  • MPLS multiprotocol label switching
  • MPLS data packets are directed from one network node to another based on short path labels rather than long network addresses.
  • An ingress node determines an appropriate MPLS header to prefix to a packet for transmission over the network based, for example, on a parameter of the data packet such as the forwarding equivalent class or quality of service class.
  • the ingress node then forwards the packet to the next router in the path as defined by the MPLS header.
  • This router swaps the packet’s outer label for another label, and then forwards the packet to the next router, and so on until the last router in the path (or egress node) is reached.
  • the last router removes the label from the packet and forwards it based on the header of its next layer, which may be defined using a different protocol, such as IPv4, IPv6, etc.
  • IPv4 IPv4, IPv6, etc.
  • Such a label- switched path may also be known as a tunnel.
  • the network 100 comprises a plurality of connected regions or areas l02a, l02b, l02c (collectively, 102).
  • these regions 102 correspond to interior gateway protocol (IGP) areas.
  • the regions 102 may correspond to autonomous systems.
  • Each region 102 comprises a plurality of nodes 108 (or routers), with each node connected to at least one other node by a link.
  • the links between nodes may be physical or virtual.
  • the regions 102 are connected to each other, and it will be observed that a node may in fact belong to more than one region 102.
  • Each region 102 comprises one or more respective route servers 106.
  • the region l02a comprises a first route server l06a; region l02b comprises a second route server l06b; and region l02c comprises a third route server l06c.
  • Each route server 106 is connected to at least one other node in its respective region 102.
  • the route servers 106 may also be termed border gateway protocol (BGP) speakers.
  • BGP border gateway protocol
  • BGP is a distance-vector routing protocol, according to which each route server 106 advertises, to other route servers or external components, the routes which are known to it.
  • each route server may maintain a routing table, comprising a list of destinations, the corresponding routes to those destinations, and a metric defining the distance from the route server to the destination (e.g., a number of hops).
  • These routing tables are advertised to other route servers or external components, so that the routes to multiple destinations can be shared across the network 100, and appropriate paths computed.
  • Each of the route servers 106 is therefore operative to communicate with a controller node 104.
  • the controller node 104 may be a software-defined networking (SDN) controller, for example. Alternatively or additionally, the controller node 104 may comprise a path computation element.
  • the controller node 104 may be coupled to each route server 106 by one or more route reflectors (not illustrated).
  • each of the route servers 106 is configured with BGP link state.
  • BGP link state as described above, is an extension to the distance vector routing protocol BGP, to enable it to carry link state information such as network topology, etc.
  • Each route server 106 obtains link-state information from the nodes and links within their respective regions 102.
  • the route servers 106 obtain link-state information by exchange of IGP messages with the nodes and links of their respective regions 102.
  • the link-state information may relate to the topology of the network within each respective region 102.
  • the link-state information comprises one or more of: one or more node parameters (e.g. identities of one or more nodes in the region); one or more link parameters (e.g., identifies of one or more links in the region, identities of local and remote nodes connected by the link, etc); and one or more prefix parameters (e.g., one or more prefixes or addresses originated by a node in the region).
  • Each route server 106 processes the link- state information for its respective region 102 into one or more BGP link state packets, and transmits the BGP link state packets to the controller node 104, and potentially also to other route servers 106.
  • the BGP link state packet may comprise the one or more node parameters, one or more link parameters, and one or more prefix parameters received in the IGP messages.
  • the controller node 104 obtains network topology information for each of the regions 102 and is able to calculate paths for requested data flows in the network 100 so as to meet one or more performance criteria.
  • the route servers 106 are configured to obtain P2MP/MP2MP capabilities of one or more nodes and links (or all nodes and links) in their respective regions 102, and to report those P2MP/MP2MP capabilities to the controller node 104.
  • Figure 2 is a flowchart of a method according to embodiments of the disclosure.
  • the method may be performed by a route server for a communication network, such as one of the route servers 106 described above with respect to Figure 1 and the network 100.
  • the route server is associated with a particular region or area (e.g., an IGP area, an autonomous system, etc) of the network, such as one of the regions 102.
  • the method begins in step 200, in which the route server receives a first message from a node in its respective region.
  • the first message comprises an indication of the P2MP and/or the MP2MP capability of the node or a link which is coupled to the node.
  • the first message may be transmitted directly from the node to the route server, or indirectly via one or more intermediate nodes (e.g., particularly if the node is not directly connected to the route server).
  • the first message may be formulated according to the interior gateway protocol (IGP).
  • Step 200 may comprise the route server receiving multiple such first messages from the nodes of its respective region.
  • Each first message comprises an indication of the P2MP and/or the MP2MP capability of a node or a link of the region, such that the route server obtains information concerning the P2MP and/or the MP2MP capabilities of the nodes and/or the links of its respective region.
  • the route server obtains information concerning the P2MP and/or the MP2MP capabilities of all nodes and links in its respective region.
  • the P2MP/MP2MP capabilities may correspond to the capability of the respective node or link to perform or support replication of data packets received from one (for P2MP) or multiple sources (for MP2MP), such that the replicated data packets can be transmitted onward over multiple separate paths to multiple, different destinations.
  • the P2MP/MP2MP capabilities of the node or link may comprise a further indication of the protocols which are supported by the node or link to establish such P2MP/MP2MP paths.
  • the P2MP/MP2MP capabilities may comprise an indication as to whether the node or link can support one or more of: label distribution protocol (LDP); protocol independent multicast (PIM); and resource reservation protocol (RSVP).
  • LDP label distribution protocol
  • PIM protocol independent multicast
  • RSVP resource reservation protocol
  • the method proceeds to step 202, in which the route server transmits a second message to a controller node, such as the controller node 104 described above with respect to Figure 1.
  • the second message comprises an indication of the P2MP/MP2MP capability of the node or link, obtained from the first message received in step 200.
  • the second message may comprise an indication of the P2MP/MP2MP capability of a single node or link, or the P2MP/MP2MP capabilities of more than one node and/or link.
  • multiple separate second messages may be transmitted in step 202 in respect of each node or link.
  • one or multiple second messages may be transmitted in step 202, with each second message comprising an indication of the P2MP/MP2MP capabilities of one or more nodes or links.
  • the second message may be formulated according to the border gateway protocol (BGP), and particularly the link state extension of BGP encoded using an NLRI format.
  • BGP border gateway protocol
  • the P2MP/MP2MP capability may be encoded in the second message as an attribute for a node or a link.
  • the indication of the P2MP/MP2MP capability for a node or link may be associated with a node or link parameters for that node or link.
  • a node P2MP/MP2MP capability attribute in the second message may be associated with a node attribute (which contains an identity of the respective node) in the second message.
  • a link P2MP/MP2MP capability attribute in the second message may be associated with a link attribute (which contains an identity of the respective link, as well as identities of local and remote nodes connected by the link) in the second message.
  • Two attributes may be associated with each other in various ways.
  • two attributes can be associated by the fact that they are both encoded in the same second message.
  • the second message contains information for multiple nodes and/or links
  • two attributes which immediately follow each other in the packet may be associated with each other.
  • a node attribute may be immediately followed by a P2MP/MP2MP capability attribute for that node, for example.
  • the second message may additionally contain an indication of the protocols which are supported by the node or link to establish such P2MP/MP2MP paths.
  • the second message may comprise an indication as to whether the node or link can support one or more of: label distribution protocol (LDP); protocol independent multicast (PIM); and resource reservation protocol (RSVP).
  • LDP label distribution protocol
  • PIM protocol independent multicast
  • RSVP resource reservation protocol
  • this indication is encoded in the same attribute which carries the P2MP/MP2MP capability information.
  • the second message may further comprise an indication of a node of the region which is to be used as the root node through which a MP2MP label switched path is created. That is, a root node is selected for MP2MP label switched paths, with all source nodes sharing a first tree which terminates at the root node and all destination nodes sharing a second tree which terminates at the root node.
  • the second message further comprises an indication of the identity or address of a root node which has been selected for this purpose. This latter indication may be part of the same attribute as the P2MP/MP2MP capabilities of a node or link, or as a separate attribute in the second message.
  • Figure 3 shows the type-length-value (TLV) format of an attribute 300 according to embodiments of the disclosure, for use in conveying the P2MP/MP2MP capability of a node or link in a second message as described above.
  • TLV type-length-value
  • the attribute comprises three fields: a type field 302, forming the initial part of the attribute; a length field 304, forming the middle part of the attribute; and a value field 306 forming the final part of the attribute 300.
  • the type field 302 comprises an indication of the type of the attribute, such as a predefined code or other identifier. In one embodiment, the type may correspond to a node P2MP/MP2MP capability attribute or a link P2MP/MP2MP capability attribute.
  • the length field 304 denotes the length of the value field. In one embodiment, the length of both attributes (i.e., node and link P2MP/MP2MP capability attributes) is equal to one byte.
  • the value field 306 comprises the indication of the P2MP/MP2MP capabilities of the particular node or link.
  • the value field 306 comprises a bitmap in which one or more bits correspond to the capability of the node or link to perform P2MP or MP2MP operations.
  • the bitmap may comprise a first bit which corresponds to the capability of the node or link to perform P2MP operations; when asserted, the first bit conveys the information that the node or link can perform P2MP operations.
  • the bitmap may comprise a second bit (in a different location to the first bit) which corresponds to the capability of the node or link to perform MP2MP operations; when asserted, the second bit conveys the information that the node or link can perform MP2MP operations.
  • the second message may comprise an indication the protocols which are supported by the node or link to establish such P2MP/MP2MP paths.
  • this indication is encoded in the same value field 306 and the bitmap used to carry the P2MP/MP2MP capability information.
  • one or more bits of the bitmap may convey the ability of the node or link to perform P2MP or MP2MP operations according to a particular one of multiple possible protocols.
  • a single bit may correspond to the capability of the node or link to perform P2MP operations according to a first protocol, while another bit may correspond to the capability of the node or link to perform P2MP operations according to a second protocol.
  • the bits of the bitmap may be arranged according to the following configuration (in any suitable order):
  • PE - P2MP/MP2MP enabled node/link (irrespective of protocol)
  • PL, PR, ML, MR and PE are five different bits of the bitmap.
  • at least one other bit of the bitmap may be utilized as an indication as to whether the node or link supports protocol independent multicast (PIM).
  • PIM protocol independent multicast
  • the identities of the nodes and links and their respective P2MP/MP2MP capabilities are collated by the route server and communicated to the controller node, which can then utilize that information to calculate paths for P2MP and MP2MP data flows which do not require ingress replication.
  • FIG 4 is a flowchart of a method according to further embodiments of the disclosure.
  • the method may be performed in a controller node for a communications network, such as the controller node 104 in the network 100 described above.
  • the controller node may be a SDN controller, for example. Additionally or alternatively, the controller node may be or comprise a path computation entity (PCE).
  • PCE path computation entity
  • the method begins in step 400, in which the controller node receives a message from a route server (e.g. one of the route servers 106) of a first region or area of the communications network.
  • the first region may be a first autonomous system, and/or a first IGP area.
  • the message comprises an indication of a P2MP/MP2MP capability of a node or link in the first region.
  • step 400 comprises the controller node receiving indications of the P2MP/MP2MP capabilities of multiple nodes and/or links in the first region. These indications may be received in one or multiple messages from the route server.
  • the message(s) may comprise an indication of the P2MP/MP2MP capability of a single node or link, or the P2MP/MP2MP capabilities of more than one node and/or link.
  • multiple separate messages may be received in step 400 in respect of each node or link.
  • one or multiple messages may be received in step 202, with each message comprising an indication of the P2MP/MP2MP capabilities of one or more nodes or links.
  • the message may be formulated according to the border gateway protocol (BGP), and particularly the link state extension of BGP encoded using an NLRI format.
  • BGP border gateway protocol
  • the P2MP/MP2MP capability may be encoded in the message as an attribute for a node or a link.
  • the indication of the P2MP/MP2MP capability for a node or link may be associated with a node or link parameters for that node or link.
  • a node P2MP/MP2MP capability attribute in the message may be associated with a node attribute (which contains an identity of the respective node) in the message.
  • a link P2MP/MP2MP capability attribute in the message may be associated with a link attribute (which contains an identity of the respective link, as well as identities of local and remote nodes connected by the link) in the message.
  • Two attributes may be associated with each other in various ways.
  • two attributes can be associated by the fact that they are both encoded in the same message.
  • the message contains information for multiple nodes and/or links
  • two attributes which immediately follow each other in the packet may be associated with each other.
  • a node attribute may be immediately followed by a P2MP/MP2MP capability attribute for that node, for example.
  • the message may additionally contain an indication of the protocols which are supported by the node or link to establish such P2MP/MP2MP paths.
  • the message may comprise an indication as to whether the node or link can support one or more of: label distribution protocol (LDP); protocol independent multicast (PIM); and resource reservation protocol (RSVP).
  • LDP label distribution protocol
  • PIM protocol independent multicast
  • RSVP resource reservation protocol
  • this indication is encoded in the same attribute which carries the P2MP/MP2MP capability information.
  • the message may further comprise an indication of a node of the region which is to be used as the root node through which a MP2MP label switched path is created. That is, a root node is selected for MP2MP label switched paths, with all source nodes sharing a first tree which terminates at the root node and all destination nodes sharing a second tree which terminates at the root node.
  • the second message further comprises an indication of the identity or address of a root node which has been selected for this purpose.
  • the message may comprise one or more attributes 300 as described above with respect to Figure 3.
  • the controller node may receive, in step 400, messages from multiple route servers of the network, with messages from each route server comprising respective indications of the P2MP/MP2MP capabilities of the nodes and/or links belonging to their respective regions.
  • the controller node is informed of the network topology of one or more regions of the network, according to the messages received from the route servers for those one or more regions.
  • the controller node is informed of the P2MP/MP2MP capabilities of one or more nodes and/or links in those regions.
  • the controller node receives a request message to compute a path for a P2MP data flow or a MP2MP data flow in the network.
  • the request message may be received from one of the route servers. In other embodiments, however, the request message may be received from a headend router 110 for the data flow in question.
  • the headend router for a data flow may correspond to an ingress node for the data flow, for example.
  • the requesting party e.g., the route server, headend router, etc
  • the path computation client may be known as the path computation client.
  • the request message may comprise an indication of one or more sources for the data flow (one source for a P2MP data flow; more than one source for a MP2MP data flow), and an indication of multiple destinations for the data flow.
  • Each node may be indicated by any suitable identifier, such as a network address (e.g., an IP address) for example.
  • the request message may further comprise an indication of a quality of service for the data flow.
  • the controller node determines a path for the P2MP or MP2MP data flow based at least in part on the P2MP/MP2MP capabilities of the nodes and/or links received in step 400. For example, the controller node may calculate a path using an algorithm which is subject to one or more constraints.
  • the P2MP/MP2MP capability information may be utilized as one such constraint, such that calculated paths may only contain forks at nodes and/or over links which are capable of P2MP and/or MP2MP operations.
  • Other constraints may seek to meet a performance target for the data flow, or the network overall.
  • the algorithm may seek to calculate paths which meet a particular quality of service, or latency (e.g., such as shortest path algorithms, etc).
  • the algorithm may seek to calculate paths which improve overall network throughput, or ensure that network load is evenly distributed.
  • Those skilled in the art will appreciate that multiple algorithms exist for the calculation of a path according to one or more metrics. The present disclosure is not limited in that regard.
  • the path may be determined based on the indication of the root node in the message.
  • the controller node initiates establishment of a tunnel according to the determined path. For example, the controller node may transmit the route to the PCC (e.g., the headend router), which can thereafter apply an appropriate label to packets of the data flow such that those packets are transmitted along the determined path.
  • the PCC may distribute the determined path to all sources and/or destinations (leafs) of the MP2MP data flow so that each source and/or destination can apply appropriate labels to packets of the data flow.
  • Figure 5 is a schematic diagram of a network node 500 according to embodiments of the disclosure.
  • the network node 500 may be configured to carry out the method described above with respect to Figure 2, for example.
  • the network node 500 comprises a route server for a communication network, such as the route server 106 described above with respect to Figure 1.
  • the network node 500 may be associated with a particular region or area of the network, such as an autonomous area and/or an IGP area.
  • the network node 500 comprises processing circuitry 502 and a machine-readable medium (such as memory) 504.
  • the machine-readable medium stores instructions which, when executed by the processing circuitry 502, cause the network node 500 to: receive a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations; and transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
  • the network node 500 also comprises one or more interfaces 506, for receiving signals from other nodes of the network and/or transmitting signals to other nodes of the network.
  • the interfaces 506 may use any appropriate communication technology, such as electronic signalling, optical signalling or wireless (radio) signalling.
  • the processing circuitry 502, the machine -readable medium 504 and the interfaces 506 are operatively coupled to each other in series.
  • these components may be coupled to each other in a different fashion, either directly or indirectly.
  • the components may be coupled to each other via a system bus or other communication line.
  • Figure 6 is a schematic diagram of a network node 600 according to embodiments of the disclosure.
  • the network node 600 may be configured to carry out the method described above with respect to Figure 2, for example.
  • the network node 600 comprises a route server for a communication network, such as the route server 106 described above with respect to Figure 1.
  • the network node 600 may be associated with a particular region or area of the network, such as an autonomous area and/or an IGP area.
  • the network node 600 comprises a receiving module 602 and a transmitting module 604.
  • the receiving module 602 is configured to receive a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations.
  • the transmitting module 604 is configured to transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
  • Figure 7 is a schematic diagram of a node 700 according to embodiments of the disclosure.
  • the network node 700 may be configured to carry out the method described above with respect to Figure 4, for example.
  • the network node 700 comprises a controller for a communication network, such as the controller node 104 described above with respect to Figure 1.
  • the communication network may comprise one or more regions or areas, such as autonomous systems and/or IGP areas.
  • the network node 700 may be an SDN controller. Alternatively or additionally, the network node 700 may be or comprise a PCE.
  • the network node 700 comprises processing circuitry 702 and a machine-readable medium (such as memory) 704.
  • the machine-readable medium stores instructions which, when executed by the processing circuitry 702, cause the network node 700 to: receive a message from a route server of a first area of the one or more area, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiate establishment of a tunnel between the source node and the destination node according to the determined path.
  • the network node 700 also comprises one or more interfaces 706, for receiving signals from other nodes of the network and/or transmitting signals to other nodes of the network.
  • the interfaces 706 may use any appropriate communication technology, such as electronic signalling, optical signalling or wireless (radio) signalling.
  • the processing circuitry 702, the machine -readable medium 704 and the interfaces 706 are operatively coupled to each other in series. In other embodiments, these components may be coupled to each other in a different fashion, either directly or indirectly. For example, the components may be coupled to each other via a system bus or other communication line.
  • Figure 8 is a schematic diagram of a network node 800 according to embodiments of the disclosure.
  • the network node 800 may be configured to carry out the method described above with respect to Figure 4, for example.
  • the network node 800 comprises a controller for a communication network, such as the controller node 104 described above with respect to Figure 1.
  • the communication network may comprise one or more regions or areas, such as autonomous systems and/or IGP areas.
  • the network node 700 may be an SDN controller. Alternatively or additionally, the network node 700 may be or comprise a PCE.
  • the network node 800 comprises a receiving module 802, a determining module 804 and an initiating module 806.
  • the receiving module 802 is configured to receive a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area.
  • the receive module 802 is further configured to receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network.
  • the determining module 804 is configured to determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area.
  • the initiating module is configured to initiate establishment of a tunnel between the source node and the destination node according to the determined path.
  • the network node 800 may also comprise one or more interface modules (not illustrated), for receiving signals from other nodes of the network and/or transmitting signals to other nodes of the network.
  • the interfaces may use any appropriate communication technology, such as electronic signalling, optical signalling or wireless (radio) signalling.
  • the modules described above with respect to Figures 6 and 8 may comprise any combination of hardware and/or software.
  • the modules are implemented entirely in hardware.
  • hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • the modules may be implemented entirely in software.
  • the modules may be implemented in combinations of hardware and software.
  • the present disclosure therefore provides methods, apparatus and machine-readable mediums which permit path calculation for P2MP/MP2MP data flows in a communications network.

Abstract

The present disclosure provides methods, apparatus and machine-readable mediums which permit path calculation for P2MP/MP2MP data flows in a communications network. In one embodiment, the disclosure provides a method performed by a route server of an area in a communication network. The method comprises: receiving a first message from a node of the area in the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations; and transmitting a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.

Description

METHODS, APPARATUS AND MACHINE-READABLE MEDIA RELATING TO PATH COMPUTATION IN A COMMUNICATION NETWORK
Technical field
Embodiments of the present disclosure relate to path computation in a communication network, and particularly provide methods, apparatus and machine-readable media relating to computation of point-to-multipoint and multipoint-to-multipoint paths in a communication network.
Background
Path computation is a well-known problem in communication networks, such as multi-protocol label switching (MPLS) networks. Path computation elements (PCEs) use one or more of various algorithms to determine an appropriate path between a source and a destination. The algorithms may seek to minimize or maximize a particular metric, whether for the path itself or the network overall. For example, in the former category the determined path may be the shortest path (e.g., as defined by the number of hops) or the path associated with the lowest latency. In the latter category, the determined path may be the path that results in the greatest overall throughput in the network, or the most efficient usage of network resources (e.g., such that particular links or nodes of the network are not overloaded, etc). Algorithms in this category may be known as traffic-engineering algorithms.
Path computation for data flows from a single source to a single destination, known as point-to-point (P2P), has been studied for several years. Recently the focus of study has changed to the computation of paths for data flows from multiple sources and/or multiple destinations. Point-to-multipoint (P2MP) data flows are flows in which the same data is sent simultaneously from a single source to multiple destinations. Multipoint-to-multipoint (MP2MP) data flows are flows in which multiple sources have the capability of transmitting the same data simultaneously to a common set of multiple destinations. See, for example, an Internet Engineering Task Force (IETF) request for comments entitled, “Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE
Label Switched Paths (LSPs)” (RFC 4875).
One problem with the computation of such paths is that the software-defined network (SDN) controller or PCE performing the calculation may not be aware of the capabilities of the nodes and links along any proposed path to perform packet replication. Some nodes may be incapable of performing the replication of data packets required if that node is to act as a branching point in the P2MP/MP2MP path. Similarly, some links (e.g., line cards for a node such as a router) may not be capable of multicast replication. To avoid this problem, the PCE may instead replicate P2MP/MP2MP functionality using ingress replication, in which multiple separate paths are calculated from each source to each of the multiple destinations. However, such an approach wastes network resources when those multiple separate paths share one or more links, with multiple copies of the same data packet being transmitted over that single link.
A solution is therefore require which permits the calculation of a P2MP or MP2MP path.
Summary
An IETF request for comments (RFC 7752) introduces the possibility of using border gateway protocol (BGP) messages to transmit link state and traffic engineering information, collected from networks, to external components like SDN controllers using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format.
BGP is a distance-vector protocol, in which nodes advertise the routes to their respective known destinations. In contrast, BGP link state extensions share topology information such as node, link and prefix information. Once this information is propagated to the external component through a BGP link state session, the external component is able to realize the logical topology of the network and can program label- switched paths based on the configured policies.
Embodiments of the present disclosure seek to advertise the P2MP and/or MP2MP capabilities of nodes and links within a network, so as to enable PCEs and SDN controllers to calculate paths for P2MP/MP2MP data flows through that network. In one embodiment, the P2MP/MP2MP capabilities are advertised using BGP link state messages or packets.
In one aspect, there is provided a method performed by a route server of an area in a communication network. The method comprises: receiving a first message from a node of the area in the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations; and transmitting a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link. Another aspect provides a method in a controller node for a communication network. The communication network comprises one or more areas. The controller node is configured to perform path computation for the communication network. The method comprises: receiving a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receiving a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determining a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiating establishment of a tunnel between the source node and the destination node according to the determined path.
A further aspect provides a route server for an area in a communication network. The route server comprises processing circuitry and a machine-readable medium storing instructions which, when executed by the processing circuitry, cause the route server to: receive a first message from a node of the area of the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point- to-multi-point, P2MP, or multi-point- to-multi-point, MP2MP, operations; and transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
Another aspect provides a controller node for a communication network. The communication network comprises one or more areas. The controller node is configured to perform path computation for the communication network. The controller node comprises processing circuitry and a machine -readable medium storing instructions which, when executed by the processing circuitry, cause the controller node to: receive a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network;
determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiate establishment of a tunnel between the source node and the destination node according to the determined path. A further aspect provides a machine-readable medium storing instructions which, when executed by processing circuitry of a route server for an area in a communication network, cause the route server to: receive a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point- to-multi-point, P2MP, or multi-point- to-multi-point, MP2MP, operations; and transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
A yet further aspect of the disclosure provides a machine-readable medium storing instructions which, when executed by processing circuitry of a controller node for a communication network, the communication network comprising one or more areas, the controller node configured to perform path computation for the communication network, cause the controller node to: receive a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiate establishment of a tunnel between the source node and the destination node according to the determined path.
Brief description of the drawings
For a better understanding of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example, to the accompanying drawings, in which:
Figure 1 illustrates a communication network according to embodiments of the disclosure; Figure 2 is a flow chart of a method in a route server according to embodiments of the disclosure;
Figure 3 shows a type-length-value (TLV) format for an attribute of a second message according to embodiments of the disclosure;
Figure 4 is a flow chart of a method in a controller node according to embodiments of the disclosure;
Figure 5 is a schematic diagram of a route server according to embodiments of the disclosure; Figure 6 is a schematic diagram of a route server according to further embodiments of the disclosure;
Figure 7 is a schematic diagram of a controller node according to embodiments of the disclosure; and
Figure 8 is a schematic diagram of a controller node according to further embodiments of the disclosure.
Detailed description
The following sets forth specific details, such as particular embodiments for purposes of explanation and not limitation. But it will be appreciated by one skilled in the art that other embodiments may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as not to obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers that are specially adapted to carry out the processing disclosed herein, based on the execution of such programs. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
In terms of computer implementation, a computer is generally understood to comprise one or more processors, one or more processing modules or one or more controllers, and the terms computer, processor, processing module and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term“processor” or“controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
Figure 1 shows a communication network 100 according to embodiments of the disclosure.
The network 100 may implement one or more protocols for transmitting data packets from one node (e.g., an ingress node) to another node (e.g., an egress node) along a defined path. In one example, the network 100 implements multiprotocol label switching (MPLS), in which label- switched paths are utilized to define the paths along which packets are transmitted.
According to MPLS, data packets are directed from one network node to another based on short path labels rather than long network addresses. An ingress node determines an appropriate MPLS header to prefix to a packet for transmission over the network based, for example, on a parameter of the data packet such as the forwarding equivalent class or quality of service class. The ingress node then forwards the packet to the next router in the path as defined by the MPLS header. This router swaps the packet’s outer label for another label, and then forwards the packet to the next router, and so on until the last router in the path (or egress node) is reached. The last router removes the label from the packet and forwards it based on the header of its next layer, which may be defined using a different protocol, such as IPv4, IPv6, etc. Such a label- switched path may also be known as a tunnel.
The network 100 comprises a plurality of connected regions or areas l02a, l02b, l02c (collectively, 102). In one embodiment, these regions 102 correspond to interior gateway protocol (IGP) areas. Additionally or alternatively, the regions 102 may correspond to autonomous systems. Each region 102 comprises a plurality of nodes 108 (or routers), with each node connected to at least one other node by a link. The links between nodes may be physical or virtual. The regions 102 are connected to each other, and it will be observed that a node may in fact belong to more than one region 102.
Each region 102 comprises one or more respective route servers 106. Thus the region l02a comprises a first route server l06a; region l02b comprises a second route server l06b; and region l02c comprises a third route server l06c. Each route server 106 is connected to at least one other node in its respective region 102. In one embodiment, the route servers 106 may also be termed border gateway protocol (BGP) speakers.
BGP is a distance-vector routing protocol, according to which each route server 106 advertises, to other route servers or external components, the routes which are known to it. For example, each route server may maintain a routing table, comprising a list of destinations, the corresponding routes to those destinations, and a metric defining the distance from the route server to the destination (e.g., a number of hops). These routing tables are advertised to other route servers or external components, so that the routes to multiple destinations can be shared across the network 100, and appropriate paths computed.
Each of the route servers 106 is therefore operative to communicate with a controller node 104. The controller node 104 may be a software-defined networking (SDN) controller, for example. Alternatively or additionally, the controller node 104 may comprise a path computation element. The controller node 104 may be coupled to each route server 106 by one or more route reflectors (not illustrated).
According to embodiments of the disclosure, each of the route servers 106 is configured with BGP link state. BGP link state, as described above, is an extension to the distance vector routing protocol BGP, to enable it to carry link state information such as network topology, etc.
Each route server 106 obtains link-state information from the nodes and links within their respective regions 102. In one embodiment, the route servers 106 obtain link-state information by exchange of IGP messages with the nodes and links of their respective regions 102. The link-state information may relate to the topology of the network within each respective region 102. For example, in one embodiment, the link-state information comprises one or more of: one or more node parameters (e.g. identities of one or more nodes in the region); one or more link parameters (e.g., identifies of one or more links in the region, identities of local and remote nodes connected by the link, etc); and one or more prefix parameters (e.g., one or more prefixes or addresses originated by a node in the region).
Each route server 106 processes the link- state information for its respective region 102 into one or more BGP link state packets, and transmits the BGP link state packets to the controller node 104, and potentially also to other route servers 106. The BGP link state packet may comprise the one or more node parameters, one or more link parameters, and one or more prefix parameters received in the IGP messages. In this way, the controller node 104 obtains network topology information for each of the regions 102 and is able to calculate paths for requested data flows in the network 100 so as to meet one or more performance criteria.
In addition, according to embodiments of the disclosure, the route servers 106 are configured to obtain P2MP/MP2MP capabilities of one or more nodes and links (or all nodes and links) in their respective regions 102, and to report those P2MP/MP2MP capabilities to the controller node 104.
Figure 2 is a flowchart of a method according to embodiments of the disclosure. The method may be performed by a route server for a communication network, such as one of the route servers 106 described above with respect to Figure 1 and the network 100. The route server is associated with a particular region or area (e.g., an IGP area, an autonomous system, etc) of the network, such as one of the regions 102.
The method begins in step 200, in which the route server receives a first message from a node in its respective region. The first message comprises an indication of the P2MP and/or the MP2MP capability of the node or a link which is coupled to the node. The first message may be transmitted directly from the node to the route server, or indirectly via one or more intermediate nodes (e.g., particularly if the node is not directly connected to the route server). The first message may be formulated according to the interior gateway protocol (IGP).
Step 200 may comprise the route server receiving multiple such first messages from the nodes of its respective region. Each first message comprises an indication of the P2MP and/or the MP2MP capability of a node or a link of the region, such that the route server obtains information concerning the P2MP and/or the MP2MP capabilities of the nodes and/or the links of its respective region. In one embodiment, the route server obtains information concerning the P2MP and/or the MP2MP capabilities of all nodes and links in its respective region.
The P2MP/MP2MP capabilities may correspond to the capability of the respective node or link to perform or support replication of data packets received from one (for P2MP) or multiple sources (for MP2MP), such that the replicated data packets can be transmitted onward over multiple separate paths to multiple, different destinations. The P2MP/MP2MP capabilities of the node or link may comprise a further indication of the protocols which are supported by the node or link to establish such P2MP/MP2MP paths. For example, the P2MP/MP2MP capabilities may comprise an indication as to whether the node or link can support one or more of: label distribution protocol (LDP); protocol independent multicast (PIM); and resource reservation protocol (RSVP).
The method proceeds to step 202, in which the route server transmits a second message to a controller node, such as the controller node 104 described above with respect to Figure 1. The second message comprises an indication of the P2MP/MP2MP capability of the node or link, obtained from the first message received in step 200. The second message may comprise an indication of the P2MP/MP2MP capability of a single node or link, or the P2MP/MP2MP capabilities of more than one node and/or link. In the former case, multiple separate second messages may be transmitted in step 202 in respect of each node or link. In the latter case, one or multiple second messages may be transmitted in step 202, with each second message comprising an indication of the P2MP/MP2MP capabilities of one or more nodes or links.
The second message may be formulated according to the border gateway protocol (BGP), and particularly the link state extension of BGP encoded using an NLRI format.
The P2MP/MP2MP capability may be encoded in the second message as an attribute for a node or a link. Thus, the indication of the P2MP/MP2MP capability for a node or link may be associated with a node or link parameters for that node or link. For example, a node P2MP/MP2MP capability attribute in the second message may be associated with a node attribute (which contains an identity of the respective node) in the second message. A link P2MP/MP2MP capability attribute in the second message may be associated with a link attribute (which contains an identity of the respective link, as well as identities of local and remote nodes connected by the link) in the second message. Two attributes may be associated with each other in various ways. For example, where the second message contains information relating to a single node or link, two attributes can be associated by the fact that they are both encoded in the same second message. Where the second message contains information for multiple nodes and/or links, two attributes which immediately follow each other in the packet may be associated with each other. In this case, a node attribute may be immediately followed by a P2MP/MP2MP capability attribute for that node, for example.
The second message may additionally contain an indication of the protocols which are supported by the node or link to establish such P2MP/MP2MP paths. For example, the second message may comprise an indication as to whether the node or link can support one or more of: label distribution protocol (LDP); protocol independent multicast (PIM); and resource reservation protocol (RSVP). In one embodiment, this indication is encoded in the same attribute which carries the P2MP/MP2MP capability information.
The second message may further comprise an indication of a node of the region which is to be used as the root node through which a MP2MP label switched path is created. That is, a root node is selected for MP2MP label switched paths, with all source nodes sharing a first tree which terminates at the root node and all destination nodes sharing a second tree which terminates at the root node. According to one embodiment, the second message further comprises an indication of the identity or address of a root node which has been selected for this purpose. This latter indication may be part of the same attribute as the P2MP/MP2MP capabilities of a node or link, or as a separate attribute in the second message.
Figure 3 shows the type-length-value (TLV) format of an attribute 300 according to embodiments of the disclosure, for use in conveying the P2MP/MP2MP capability of a node or link in a second message as described above.
The attribute comprises three fields: a type field 302, forming the initial part of the attribute; a length field 304, forming the middle part of the attribute; and a value field 306 forming the final part of the attribute 300. The type field 302 comprises an indication of the type of the attribute, such as a predefined code or other identifier. In one embodiment, the type may correspond to a node P2MP/MP2MP capability attribute or a link P2MP/MP2MP capability attribute. The length field 304 denotes the length of the value field. In one embodiment, the length of both attributes (i.e., node and link P2MP/MP2MP capability attributes) is equal to one byte.
The value field 306 comprises the indication of the P2MP/MP2MP capabilities of the particular node or link. In one embodiment, the value field 306 comprises a bitmap in which one or more bits correspond to the capability of the node or link to perform P2MP or MP2MP operations. For example, the bitmap may comprise a first bit which corresponds to the capability of the node or link to perform P2MP operations; when asserted, the first bit conveys the information that the node or link can perform P2MP operations. The bitmap may comprise a second bit (in a different location to the first bit) which corresponds to the capability of the node or link to perform MP2MP operations; when asserted, the second bit conveys the information that the node or link can perform MP2MP operations.
As noted above, in some embodiments the second message may comprise an indication the protocols which are supported by the node or link to establish such P2MP/MP2MP paths. In one embodiment, this indication is encoded in the same value field 306 and the bitmap used to carry the P2MP/MP2MP capability information.
In this embodiment, one or more bits of the bitmap may convey the ability of the node or link to perform P2MP or MP2MP operations according to a particular one of multiple possible protocols. Thus a single bit may correspond to the capability of the node or link to perform P2MP operations according to a first protocol, while another bit may correspond to the capability of the node or link to perform P2MP operations according to a second protocol. In one particular embodiment, the bits of the bitmap may be arranged according to the following configuration (in any suitable order):
PL - P2MP LDP enabled node/link
PR - P2MP RSVP enabled node/link
ML - MP2MP LDP enabled node/link
MR - MP2MP RSVP enabled node/link
PE - P2MP/MP2MP enabled node/link (irrespective of protocol)
Where PL, PR, ML, MR and PE are five different bits of the bitmap. In one embodiment, at least one other bit of the bitmap may be utilized as an indication as to whether the node or link supports protocol independent multicast (PIM).
Thus the identities of the nodes and links and their respective P2MP/MP2MP capabilities are collated by the route server and communicated to the controller node, which can then utilize that information to calculate paths for P2MP and MP2MP data flows which do not require ingress replication.
Figure 4 is a flowchart of a method according to further embodiments of the disclosure. The method may be performed in a controller node for a communications network, such as the controller node 104 in the network 100 described above. The controller node may be a SDN controller, for example. Additionally or alternatively, the controller node may be or comprise a path computation entity (PCE).
The method begins in step 400, in which the controller node receives a message from a route server (e.g. one of the route servers 106) of a first region or area of the communications network. The first region may be a first autonomous system, and/or a first IGP area. The message comprises an indication of a P2MP/MP2MP capability of a node or link in the first region.
In one embodiment, step 400 comprises the controller node receiving indications of the P2MP/MP2MP capabilities of multiple nodes and/or links in the first region. These indications may be received in one or multiple messages from the route server.
The message(s) may comprise an indication of the P2MP/MP2MP capability of a single node or link, or the P2MP/MP2MP capabilities of more than one node and/or link. In the former case, multiple separate messages may be received in step 400 in respect of each node or link. In the latter case, one or multiple messages may be received in step 202, with each message comprising an indication of the P2MP/MP2MP capabilities of one or more nodes or links.
The message may be formulated according to the border gateway protocol (BGP), and particularly the link state extension of BGP encoded using an NLRI format.
The P2MP/MP2MP capability may be encoded in the message as an attribute for a node or a link. Thus, the indication of the P2MP/MP2MP capability for a node or link may be associated with a node or link parameters for that node or link. For example, a node P2MP/MP2MP capability attribute in the message may be associated with a node attribute (which contains an identity of the respective node) in the message. A link P2MP/MP2MP capability attribute in the message may be associated with a link attribute (which contains an identity of the respective link, as well as identities of local and remote nodes connected by the link) in the message. Two attributes may be associated with each other in various ways. For example, where the message contains information relating to a single node or link, two attributes can be associated by the fact that they are both encoded in the same message. Where the message contains information for multiple nodes and/or links, two attributes which immediately follow each other in the packet (or utilize some other predefined order) may be associated with each other. In this case, a node attribute may be immediately followed by a P2MP/MP2MP capability attribute for that node, for example.
The message may additionally contain an indication of the protocols which are supported by the node or link to establish such P2MP/MP2MP paths. For example, the message may comprise an indication as to whether the node or link can support one or more of: label distribution protocol (LDP); protocol independent multicast (PIM); and resource reservation protocol (RSVP). In one embodiment, this indication is encoded in the same attribute which carries the P2MP/MP2MP capability information.
The message may further comprise an indication of a node of the region which is to be used as the root node through which a MP2MP label switched path is created. That is, a root node is selected for MP2MP label switched paths, with all source nodes sharing a first tree which terminates at the root node and all destination nodes sharing a second tree which terminates at the root node. According to one embodiment, the second message further comprises an indication of the identity or address of a root node which has been selected for this purpose.
In one embodiment, the message may comprise one or more attributes 300 as described above with respect to Figure 3.
The controller node may receive, in step 400, messages from multiple route servers of the network, with messages from each route server comprising respective indications of the P2MP/MP2MP capabilities of the nodes and/or links belonging to their respective regions. Thus the controller node is informed of the network topology of one or more regions of the network, according to the messages received from the route servers for those one or more regions. In addition, the controller node is informed of the P2MP/MP2MP capabilities of one or more nodes and/or links in those regions.
In step 402, the controller node receives a request message to compute a path for a P2MP data flow or a MP2MP data flow in the network. The request message may be received from one of the route servers. In other embodiments, however, the request message may be received from a headend router 110 for the data flow in question. The headend router for a data flow may correspond to an ingress node for the data flow, for example. In embodiments where the request message conforms to the patent computation element protocol, the requesting party (e.g., the route server, headend router, etc) may be known as the path computation client.
The request message may comprise an indication of one or more sources for the data flow (one source for a P2MP data flow; more than one source for a MP2MP data flow), and an indication of multiple destinations for the data flow. Each node may be indicated by any suitable identifier, such as a network address (e.g., an IP address) for example. The request message may further comprise an indication of a quality of service for the data flow.
In step 404, the controller node determines a path for the P2MP or MP2MP data flow based at least in part on the P2MP/MP2MP capabilities of the nodes and/or links received in step 400. For example, the controller node may calculate a path using an algorithm which is subject to one or more constraints. The P2MP/MP2MP capability information may be utilized as one such constraint, such that calculated paths may only contain forks at nodes and/or over links which are capable of P2MP and/or MP2MP operations. Other constraints may seek to meet a performance target for the data flow, or the network overall. In the former category, the algorithm may seek to calculate paths which meet a particular quality of service, or latency (e.g., such as shortest path algorithms, etc). In the latter category, the algorithm may seek to calculate paths which improve overall network throughput, or ensure that network load is evenly distributed. Those skilled in the art will appreciate that multiple algorithms exist for the calculation of a path according to one or more metrics. The present disclosure is not limited in that regard.
In the case of MP2MP data flows, the path may be determined based on the indication of the root node in the message.
In step 406, once the path has been determined, the controller node initiates establishment of a tunnel according to the determined path. For example, the controller node may transmit the route to the PCC (e.g., the headend router), which can thereafter apply an appropriate label to packets of the data flow such that those packets are transmitted along the determined path. In the case of MP2MP data flows, the PCC may distribute the determined path to all sources and/or destinations (leafs) of the MP2MP data flow so that each source and/or destination can apply appropriate labels to packets of the data flow.
Figure 5 is a schematic diagram of a network node 500 according to embodiments of the disclosure. The network node 500 may be configured to carry out the method described above with respect to Figure 2, for example. In one embodiment, the network node 500 comprises a route server for a communication network, such as the route server 106 described above with respect to Figure 1. The network node 500 may be associated with a particular region or area of the network, such as an autonomous area and/or an IGP area.
The network node 500 comprises processing circuitry 502 and a machine-readable medium (such as memory) 504. The machine-readable medium stores instructions which, when executed by the processing circuitry 502, cause the network node 500 to: receive a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations; and transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
In the illustrated embodiment, the network node 500 also comprises one or more interfaces 506, for receiving signals from other nodes of the network and/or transmitting signals to other nodes of the network. The interfaces 506 may use any appropriate communication technology, such as electronic signalling, optical signalling or wireless (radio) signalling.
In the illustrated embodiment, the processing circuitry 502, the machine -readable medium 504 and the interfaces 506 are operatively coupled to each other in series. In other embodiments, these components may be coupled to each other in a different fashion, either directly or indirectly. For example, the components may be coupled to each other via a system bus or other communication line.
Figure 6 is a schematic diagram of a network node 600 according to embodiments of the disclosure. The network node 600 may be configured to carry out the method described above with respect to Figure 2, for example. In one embodiment, the network node 600 comprises a route server for a communication network, such as the route server 106 described above with respect to Figure 1. The network node 600 may be associated with a particular region or area of the network, such as an autonomous area and/or an IGP area.
The network node 600 comprises a receiving module 602 and a transmitting module 604. The receiving module 602 is configured to receive a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations. The transmitting module 604 is configured to transmit a second message to a controller node configured to perform path computation for the communication system, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
Figure 7 is a schematic diagram of a node 700 according to embodiments of the disclosure. The network node 700 may be configured to carry out the method described above with respect to Figure 4, for example. In one embodiment, the network node 700 comprises a controller for a communication network, such as the controller node 104 described above with respect to Figure 1. The communication network may comprise one or more regions or areas, such as autonomous systems and/or IGP areas. The network node 700 may be an SDN controller. Alternatively or additionally, the network node 700 may be or comprise a PCE.
The network node 700 comprises processing circuitry 702 and a machine-readable medium (such as memory) 704. The machine-readable medium stores instructions which, when executed by the processing circuitry 702, cause the network node 700 to: receive a message from a route server of a first area of the one or more area, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area; receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and initiate establishment of a tunnel between the source node and the destination node according to the determined path.
In the illustrated embodiment, the network node 700 also comprises one or more interfaces 706, for receiving signals from other nodes of the network and/or transmitting signals to other nodes of the network. The interfaces 706 may use any appropriate communication technology, such as electronic signalling, optical signalling or wireless (radio) signalling. In the illustrated embodiment, the processing circuitry 702, the machine -readable medium 704 and the interfaces 706 are operatively coupled to each other in series. In other embodiments, these components may be coupled to each other in a different fashion, either directly or indirectly. For example, the components may be coupled to each other via a system bus or other communication line.
Figure 8 is a schematic diagram of a network node 800 according to embodiments of the disclosure. The network node 800 may be configured to carry out the method described above with respect to Figure 4, for example. In one embodiment, the network node 800 comprises a controller for a communication network, such as the controller node 104 described above with respect to Figure 1. The communication network may comprise one or more regions or areas, such as autonomous systems and/or IGP areas. The network node 700 may be an SDN controller. Alternatively or additionally, the network node 700 may be or comprise a PCE.
The network node 800 comprises a receiving module 802, a determining module 804 and an initiating module 806. The receiving module 802 is configured to receive a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area. The receive module 802 is further configured to receive a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network. The determining module 804 is configured to determine a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area. The initiating module is configured to initiate establishment of a tunnel between the source node and the destination node according to the determined path.
The network node 800 may also comprise one or more interface modules (not illustrated), for receiving signals from other nodes of the network and/or transmitting signals to other nodes of the network. The interfaces may use any appropriate communication technology, such as electronic signalling, optical signalling or wireless (radio) signalling.
The modules described above with respect to Figures 6 and 8 may comprise any combination of hardware and/or software. For example, in one embodiment, the modules are implemented entirely in hardware. As noted above, hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. In another embodiment, the modules may be implemented entirely in software. In yet further embodiments, the modules may be implemented in combinations of hardware and software.
The present disclosure therefore provides methods, apparatus and machine-readable mediums which permit path calculation for P2MP/MP2MP data flows in a communications network.
It should be noted that the above-mentioned embodiments illustrate rather than limit the concepts disclosed herein, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended following claims. The word“comprising” does not exclude the presence of elements or steps other than those listed in a statement,“a” or“an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the statements. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1. A method performed by a route server (106) of an area (102) in a communication network (100), the method comprising:
receiving (200) a first message from a node (108) of the area (102) in the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi -point, MP2MP, operations; and
transmitting (202) a second message to a controller node (104) configured to perform path computation for the communication network, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
2. The method according to claim 1, wherein the indication of the P2MP or MP2MP capability in the second message comprises a bitmap (306), one or more bits of the bitmap corresponding to a capability of the node or link to perform one or more of: P2MP operations and MP2MP operations.
3. The method according to claim 1 or 2, wherein the second message further comprises an indication of a capability of the node or the link to utilize one or more of: the label distribution protocol; protocol independent multicast; and the resource reservation protocol.
4. The method according to claim 3 as dependent on claim 2, wherein the one or more bits of the bitmap (306) further represent a capability of the node or link to utilize one or more of: the label distribution protocol; protocol independent multicast; and the resource reservation protocol.
5. The method according to claim 4, wherein at least one of the bits of the bitmap (306) represents both the P2MP or MP2MP capability of the node or link and the capability of the node or link to utilize one or more of: the label distribution protocol; protocol independent multicast; and the resource reservation protocol.
6. The method according to any one of the preceding claims, wherein the second message further comprises an indication of an identity of the node or the link.
7. The method according to any one of the preceding claims, wherein the second message further comprises an indication of a node of the area which is selected as a root node for MP2MP data flows.
8. The method according to any one of the preceding claims, wherein the first message comprises an interior gateway protocol packet.
9. The method according to any one of the preceding claims, wherein the second message comprises a border gateway protocol link state packet.
10. The method according to claim 9, wherein the indication of the P2MP or MP2MP capability of the node or link comprises an attribute of the border gateway protocol link state packet.
11. The method according to any one of the preceding claims, wherein the controller node (104) comprises a software-defined network controller.
12. A method in a controller node (104) for a communication network (100), the communication network comprising one or more areas (102), the controller node configured to perform path computation for the communication network, the method comprising:
receiving (400) a message from a route server (106) of a first area (102) of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area;
receiving (402) a request message to compute a path for a P2MP or MP2MP data flow between a source node (110) and a destination node (108) of the communication network;
determining (404) a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and
initiating (406) establishment of a tunnel between the source node and the destination node according to the determined path.
13. The method according to claim 12, wherein the indication of the P2MP or MP2MP capability in the message comprises a bitmap (306), one or more bits of the bitmap corresponding to a capability of the node or link to perform one or more of: P2MP operations and MP2MP operations.
14. The method according to claim 12 or 13, wherein the message further comprises an indication of an identity of the node or the link.
15. The method according to any one of claims 12 to 14, wherein the message comprises a border gateway protocol link state packet.
16. The method according to claim 15, wherein the indication of the P2MP or MP2MP capability of the node or link comprises an attribute of the border gateway protocol link state packet.
17. The method according to any one of claims 12 to 16, wherein the request message comprises a path computation element protocol message.
18. The method according to any one of claims 12 to 17, wherein the controller node (104) comprises a software-defined network controller.
19. A route server (106, 500) for an area (102) in a communication network (100), the route server comprising processing circuitry (502) and a machine-readable medium (504) storing instructions which, when executed by the processing circuitry, cause the route server to:
receive (200) a first message from a node (108) of the area of the communication network, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi -point, MP2MP, operations; and
transmit (202) a second message to a controller node (104) configured to perform path computation for the communication network, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
20. The route server according to claim 19, wherein the indication of the P2MP or MP2MP capability in the second message comprises a bitmap (306), one or more bits of the bitmap corresponding to a capability of the node or link to perform one or more of: P2MP operations and MP2MP operations.
21. The route server according to claim 19 or 20, wherein the second message further comprises an indication of a capability of the node or the link to utilize one or more of: the label distribution protocol; protocol independent multicast; and the resource reservation protocol.
22. The route server according to claim 21 as dependent on claim 20, wherein the one or more bits of the bitmap (306) further represent a capability of the node or link to utilize one or more of: the label distribution protocol; protocol independent multicast; and the resource reservation protocol.
23. The route server according to claim 22, wherein at least one of the bits of the bitmap (306) represents both the P2MP or MP2MP capability of the node or link and the capability of the node or link to utilize one or more of: the label distribution protocol; protocol independent multicast; and the resource reservation protocol.
24. The route server according to any one of claims 19 to 23, wherein the second message further comprises an indication of an identity of the node or the link.
25. The route server according to any one of claims 19 to 24, wherein the first message comprises an interior gateway protocol packet.
26. The route server according to any one of claims 19 to 25, wherein the second message comprises a border gateway protocol link state packet.
27. The route server according to claim 26, wherein the indication of the P2MP or MP2MP capability of the node or link comprises an attribute of the border gateway protocol link state packet.
28. The route server according to any one of claims 19 to 27, wherein the controller node (104) comprises a software-defined network controller.
29. A controller node (104, 700) for a communication network (100), the communication network comprising one or more areas (102), the controller node configured to perform path computation for the communication network, the controller node comprising processing circuitry (702) and a machine -readable medium (704) storing instructions which, when executed by the processing circuitry, cause the controller node to:
receive (400) a message from a route server (106) of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area;
receive (402) a request message to compute a path for a P2MP or MP2MP data flow between a source node (110) and a destination node (108) of the communication network;
determine (404) a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and
initiate (406) establishment of a tunnel between the source node and the destination node according to the determined path.
30. The controller node according to claim 29, wherein the indication of the P2MP or MP2MP capability in the message comprises a bitmap (306), one or more bits of the bitmap corresponding to a capability of the node or link to perform one or more of: P2MP operations and MP2MP operations.
31. The controller node according to claim 29 or 30, wherein the message comprises a border gateway protocol link state packet.
32. The controller node according to claim 31, wherein the indication of the P2MP or MP2MP capability of the node or link comprises an attribute of the border gateway protocol link state packet.
33. The controller node according to any one of claims 29 to 32, wherein the request message comprises a path computation element protocol message.
34. A machine-readable medium storing instructions which, when executed by processing circuitry of a route server (106) for an area (102) in a communication network (100), cause the route server to:
receive (200) a first message from a node of the area, the first message comprising an indication of a capability of the node or a link coupled to the node to perform point-to-multi-point, P2MP, or multi-point-to-multi-point, MP2MP, operations; and
transmit (202) a second message to a controller node configured to perform path computation for the communication network, the second message comprising an indication of the P2MP or MP2MP capability of the node or the link.
35. A machine-readable medium storing instructions which, when executed by processing circuitry of a controller node (104) for a communication network (100), the communication network comprising one or more areas (102), the controller node configured to perform path computation for the communication network, cause the controller node to:
receive (400) a message from a route server of a first area of the one or more areas, the message comprising an indication of the P2MP or MP2MP capability of one or more nodes or links of the first area;
receive (402) a request message to compute a path for a P2MP or MP2MP data flow between a source node and a destination node of the communication network; determine (404) a path for the P2MP or MP2MP data flow based at least in part on the P2MP or MP2MP capability of the one or more nodes or links of the first area; and
initiate (406) establishment of a tunnel between the source node and the destination node according to the determined path.
PCT/IN2018/050493 2018-07-27 2018-07-27 Methods, apparatus and machine-readable media relating to path computation in a communication network WO2020021558A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/IN2018/050493 WO2020021558A1 (en) 2018-07-27 2018-07-27 Methods, apparatus and machine-readable media relating to path computation in a communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IN2018/050493 WO2020021558A1 (en) 2018-07-27 2018-07-27 Methods, apparatus and machine-readable media relating to path computation in a communication network

Publications (1)

Publication Number Publication Date
WO2020021558A1 true WO2020021558A1 (en) 2020-01-30

Family

ID=69181396

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IN2018/050493 WO2020021558A1 (en) 2018-07-27 2018-07-27 Methods, apparatus and machine-readable media relating to path computation in a communication network

Country Status (1)

Country Link
WO (1) WO2020021558A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230239176A1 (en) * 2020-10-22 2023-07-27 Ciena Corporation Bitmap signaling of services using Segment Routing

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180034730A1 (en) * 2013-10-11 2018-02-01 Futurewei Technologies, Inc. Using PCE as SDN controller

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180034730A1 (en) * 2013-10-11 2018-02-01 Futurewei Technologies, Inc. Using PCE as SDN controller

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
QUINTIN ZHAO ET AL.: "Background, section 1.2. ''Using the PCE as the Central Controller (PCECC) Approach'', section 3 ''PCEP Requirements'', section 4 ''Use Cases of PCECC for Label Resource Reservations", THE USE CASES FOR USING PCE AS THE CENTRAL CONTROLLER(PCECC) OF LSPS DRAFT-ZHAO-PCE-CENTRAL-CONTROLLER-USER-CASES-02, 26 October 2016 (2016-10-26), XP015107546 *
R. AGGARWAL ET AL.: "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs", NETWORK WORKING GROUP, 1 May 2007 (2007-05-01), XP015052419 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230239176A1 (en) * 2020-10-22 2023-07-27 Ciena Corporation Bitmap signaling of services using Segment Routing

Similar Documents

Publication Publication Date Title
US11483237B2 (en) BIER traffic engineering (BIER-TE) using unicast MPLS-TE tunnels
US10616063B1 (en) Stateless multicast in IP networks
USRE47260E1 (en) System and method for point to multipoint inter-domain MPLS traffic engineering path calculation
US9860161B2 (en) System and method for computing a backup ingress of a point-to-multipoint label switched path
US9231851B2 (en) System and method for computing point-to-point label switched path crossing multiple domains
EP3103230B1 (en) Software defined networking (sdn) specific topology information discovery
US8830826B2 (en) System and method for computing a backup egress of a point-to-multi-point label switched path
US8077713B2 (en) Dynamic update of a multicast tree
US20160006614A1 (en) Source Routing Using Path Computation Elements
CN109417508B (en) Method and device for constructing hierarchical Path Computation Element (PCE) network topology
US8570871B2 (en) Signaling extension for a label switched path over a composite link
CN112118178B (en) Network device and method for class-based traffic engineering in an IP network
WO2020021558A1 (en) Methods, apparatus and machine-readable media relating to path computation in a communication network
US11303549B2 (en) Segmented traceroute for segment routing traffic engineering

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18927516

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18927516

Country of ref document: EP

Kind code of ref document: A1