X channel to zone in zone routing

An apparatus for zone routing comprising a transmitter coupled to one or more communication nodes in a network, wherein the communication nodes correspond to less than all edge nodes of the network, a receiver coupled to the communication nodes, and a processor coupled to the transmitter and the receiver, wherein the processor is configured to compute a first path for a label-switched path (LSP) through the network, wherein the first path extends from an ingress node of the edge nodes to an egress node of the edge nodes, obtain a second path that traverses through a first communication node of the communication nodes available to the egress node, and send, via the transmitter, a first LSP creation request message to the first communication node requesting creation of the LSP along the first path.

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Routing is a process of forwarding network traffic to destinations. Source routing is a mechanism that partially or completely specifies, within a source route header, a route that a packet may travel via a network. The source route header may comprise a strict list or a loose list of links and/or nodes to traverse. A strict list explicitly lists all of the links and/or nodes a packet may be transported over, whereas a loose list specifies one or more links and/or nodes that the packet may traverse through to reach a destination, but may not include all the links and/or nodes that a packet may traverse through to reach the destination.

Segment routing (SR) is based on source routing, where a node steers a packet through an ordered list of instructions, called segments. A segment may represent any instruction, and may be topological or service-based. A segment may be identified by a segment label. In an SR network, a route may be formed from a plurality of segments and may be indicated as an ordered list of segment labels in a source route header. SR may be applied to multiprotocol label switching (MPLS) networks and Internet protocol version 6 (IPv6) networks.

SUMMARY

In one embodiment, the disclosure includes an apparatus for zone routing, comprising a transmitter coupled to one or more communication nodes in a network, wherein the communication nodes correspond to less than all edge nodes of the network, a receiver coupled to the communication nodes, and a processor coupled to the transmitter and the receiver, wherein the processor is configured to compute a first path for a label switched path (LSP) through the network, wherein the first path extends from an ingress node of the edge nodes to an egress node of the edge nodes, obtain a second path that traverses through a first communication node of the communication nodes available to the egress node, and send, via the transmitter, a first LSP creation request message to the first communication node requesting creation of the LSP along the first path. In some embodiments, the disclosure also includes wherein the first communication node corresponds to a first of the edge nodes of the network, and/or wherein the first communication node corresponds to an internal node of the network, and/or wherein the processor is further configured to receive an LSP creation response message from a second communication node of the communication nodes, wherein the communication nodes available have third paths from the ingress node of the LSP, wherein the second communication node has a shortest third path from the ingress node, and wherein the LSP creation response message indicates a creation status of the LSP along the first path, and/or wherein the processor is further configured to obtain a global identifier (ID) for identifying the LSP, wherein the LSP creation request message comprises the global ID, send, via the transmitter, an LSP deletion request message to the first communication node requesting deletion of the LSP from the network, wherein the LSP deletion request message comprises the global ID, and receive, via the receiver, an LSP deletion response message from the second communication node indicating a deletion status of the LSP along the first path, and/or wherein the second communication node and the first communication node correspond to a same node in the network, and/or further comprising a memory coupled to the processor and configured to store a routing information base (RIB) identifying one of the communication nodes available as a next-hop node for each of a plurality of fourth paths to nodes in the network, wherein the plurality of paths comprises the second path, and wherein the processor is further configured to determine that the second path is a shortest path among the plurality of fourth paths to the egress node according to the RIB, and select the first communication node according to the shortest path determined from the RIB.

In another embodiment, the disclosure includes a network element (NE) in a zone routing network, comprising a memory configured to store a RIB identifying a first next-hop node for a first path in the network to reach a network controller of the network via a first communication node in the network, wherein the first communication node is directly associated with the network controller, a receiver configured to receive a first LSP creation request message requesting creation of a first LSP through the network, wherein the first LSP creation request message indicates an ingress node of the first LSP, a processor coupled to the memory and the receiver, wherein the processor is configured to determine that the NE corresponds to the ingress node of the first LSP, and a transmitter coupled to the processor and configured to send a first LSP creation response message towards the network controller via the first communication node according to the first path to indicate a creation status of the first LSP, and/or wherein the memory is further configured to store a forwarding information base (FIB) comprising forwarding instructions, wherein the first LSP creation request message is received from a next downstream node along the first LSP, wherein the first LSP creation request message further indicates a global ID identifying the first LSP, a local label associated with the first LSP, and an address of the network controller, and wherein the processor is further configured to generate a FIB entry according to the local label, and generate the first LSP creation response message according to the global ID and the address of the network controller, and/or wherein the receiver is further configured to receive an LSP deletion request message from the next downstream node requesting deletion of the first LSP, wherein the processor is further configured to delete the FIB entry in response to the LSP deletion request message, and wherein the transmitter is further configured to send an LSP deletion response message towards the network controller via the first communication node according to the first path to indicate a deletion status of the first LSP, and/or wherein the memory is further configured to store a FIB comprising forwarding instructions, wherein the receiver is further configured to receive a second LSP creation request message from the first communication node requesting creation of a second LSP through the network, wherein the second LSP creation request message indicates a global ID of the second LSP and an egress node of the second LSP, wherein the processor is further configured to determine that the NE corresponds to the egress node of the second LSP, allocate a local label for the second LSP, generate a FIB entry according to the local label, and generate a third LSP creation request message according to the second LSP creation request message and the local label, and wherein the transmitter is further configured to send the third LSP creation request message to a next upstream node along the second LSP in response to the second LSP creation request message, and/or wherein the receiver is further configured to receive a first LSP deletion request message from the first communication node requesting deletion of the second LSP, wherein the processor is further configured to delete the FIB entry, release the local label, and generate a second LSP deletion request message according to the first LSP deletion request message and the local label, and wherein the transmitter is further configured to send the second LSP deletion request message to the next upstream node in response to the first LSP deletion request message, and/or wherein the receiver is further configured to receive a second LSP creation response message from another NE, wherein the second LSP creation response message is associated with a second LSP, and wherein the transmitter is further configured to send a first acknowledgement to the another NE, and send a third LSP creation response message to the first next-hop node according to the second LSP creation response message, wherein the third LSP creation response message comprises a same content as the second LSP creation response message, and/or wherein the receiver is further configured to receive a first LSP deletion response message from another NE, wherein the first LSP deletion response message is associated with a second LSP, and wherein the transmitter is further configured to send a first acknowledgement to the another NE, and send a second LSP deletion response message to the first next-hop node according to the first LSP deletion response message, wherein the second LSP deletion response message comprises a same content as the first LSP deletion response message, and/or wherein the receiver is further configured to receive a second LSP creation request message from another NE, wherein the second LSP creation request message is associated with a second LSP, wherein the RIB further identifies a second next-hop node for a second shortest path in the network that reaches an egress node of the second LSP, and wherein the transmitter is further configured to send a first acknowledgement to the another NE, and send a third LSP creation request message to the second next-hop node according to the second LSP creation request message, wherein the third LSP creation request message comprises a same content as the second LSP creation request message, and/or wherein the receiver is further configured to receive a first LSP deletion request message from the another NE, and wherein the transmitter is further configured to send a second acknowledgement to the another NE, and send a second LSP deletion request message to the second next-hop node according to the first LSP deletion request message, wherein the second LSP deletion request message comprises a same content as the first LSP deletion request message.

In yet another embodiment, the disclosure includes a method implemented by a network controller in a zone routing network comprising a plurality of edge nodes and one or more communication nodes, the method comprising computing, via a processor of the network controller, a first path through the network for a LSP, wherein the first path extends from an ingress node of the edge nodes to an egress node of the edge nodes, obtaining, via the processor, a second path that traverses through a first communication node of the communication nodes available to the egress node, and sending, via a transmitter of the network controller, a first LSP creation request message to the first communication node requesting creation of the LSP along the first path, wherein the communication are not all the edge nodes. In some embodiments, the disclosure also includes receiving, via a receiver of the network controller, an LSP creation response message from a second communication node of the communication nodes, wherein the communication nodes available have third paths from the ingress node of the LSP, wherein the second communication node has a shortest third path from the ingress node, and wherein the LSP creation response message indicates a creation status of the LSP along the first path, and/or wherein the first communication node corresponds to a first of the edge nodes of the network, and/or wherein the first communication node corresponds to an internal node of the network.

DETAILED DESCRIPTION

FIG. 1is a schematic diagram of an embodiment of an SDN system100. The system100comprises an SDN controller110and a network130. The network130comprises a plurality of edge nodes121, shown as PE1, PE2, PE3, and PE4, and a plurality of internal nodes122, shown as P1, P2, P3, and P4, interconnected by a plurality of links131. The edge nodes121are located at an edge or a boundary of the network130. The internal nodes122are located within an area of the network130. The underlying infrastructure of the network130may be any types of networks such as an electrical network, an optical network, or combinations thereof. The links131may comprise physical links such as fiber optic links, electrical links, wireless links and/or logical links used to transport data in the network130. The network130may operate under a single network administrative domain or multiple network administrative domains. The network130may employ any forwarding data plane such as an MPLS forwarding data plane. The SDN controller110is communicatively coupled to all edge nodes121and all internal nodes122of the network130. The system100decouples network control and network forwarding functions.

The SDN controller110may be a virtual machine (VM), a hypervisor, or any other device configured to manage and control the network130. The SDN controller110obtains and/or maintains a full topology view of the network130. The SDN controller110computes forwarding paths through the network130according to the topology information. For example, the SDN controller110may employ a shortest path algorithm to determine a best path between a source-destination pair in the network130. After computing the forwarding paths, the SDN controller110sends forwarding instructions to the edge nodes121and the internal nodes122to instruct the edge nodes121and the internal nodes122to forward packets according to the computed forwarding paths. The forwarding instructions may be dependent on the routing protocol. The SDN controller110communicates with all edge nodes121and all internal nodes122via a plurality of communication channels140. The communication channels140are also referred to as controller-network communication channels. In an embodiment, the communication channels140are OpenFlow channels as described in the OpenFlow switch specification version 1.5.1 defined by Open Networking Foundation (ONF).

The edge nodes121and the internal nodes122are software programmable network devices configured to perform forwarding functions in the network130according to forwarding instructions received from the SDN controller110via the communication channels140. The edge nodes121are further configured to function as access points or interconnection points between the network130and other networks, which may be similar to the network130or different from the network130, or other network domains. For example, the edge nodes121may establish networking sessions and/or services with different networks, but may not exchange topology information across the different networks.

The decoupling of the control plane from the data plane in SDN networks such as the system100allows for centralization of network control, enabling effective policy administration and flexible management. The centralization of network control facilitates various network functionalities, such as network measurements, traffic engineering (TE), enhanced quality of services, and enhanced access control. Thus, many organizations have started to deploy SDN networks. However, the migration of conventional networks to SDN networks may be complex and time consuming. For example, hardware-based network devices are required to be replaced with programmable or software-based network devices. In addition, the number of communication channels such as the communication channels140is large in SDN networks.

FIG. 2is a schematic diagram of a zone-edge routing system200. The system200is described in U.S. patent application Ser. No. 14/737,142 by Huaimo Chen, et al., and titled “Zone Routing System,” (“'142 application”), which is incorporated by reference. The system200is similar to the system100, but reduces the number of communication channels140and only requires upgrades or migration of the edge nodes121. The system200comprises a ZR controller210communicatively coupled to a network230similar to the network130via a plurality of communication channels240similar to the communication channels140. The network230comprises a plurality of edge nodes221, shown as PE1, PE2, PE3, and PE4, and a plurality of internal nodes222, shown as P1, P2, P3, and P4. The ZR controller210performs similar network control and management as the SDN controller110. The edge nodes221and the internal nodes222are similar to the edge nodes121and the internal nodes122, respectively. However, the internal nodes222do not directly communicate with the ZR controller210.

In an embodiment, the network230employs an MPLS forwarding data plane, where packets are encapsulated with an ordered list of labels identifying a corresponding forwarding path. In such an embodiment, the ZR controller210computes shortest paths for LSPs in the network230according to certain constraints and maintains information and states associated with the LSPs. The ZR controller210communicates with the edge nodes221to instruct establishment and tear-down of LSPs across the network230. Thus, the edge nodes221and the internal nodes222do not employ any label distribution protocol such as the resource reservation protocol (RSVP) and the label distribution protocol (LDP) that is commonly employed in conventional MPLS networks. In addition, the edge nodes221and the internal nodes222do not maintain any LSP states. As an example, the ZR controller210computes a shortest path for an LSP251across the network230. The LSP251begins at the edge node PE1221, traverses through the internal nodes P1and P2222, and ends at the edge node PE4221. The edge node PE1221is referred to as an ingress node or a source node of the LSP251. The edge node PE4221is referred to as an egress node or a destination node of the LSP251. The internal nodes P1and P2222are referred to as transit nodes of the LSP251. To create or establish the LSP251, the ZR controller210sends an LSP creation instruction to the edge node PE4221corresponding to the egress node of the LSP251. The edge node PE4221initiates creation of the LSP251along the path of the LSP251. When the creation of the LSP251is completed, the edge node PE1221corresponding to the ingress node of the LSP251sends an LSP creation status to the ZR controller210. The LSP251may be deleted by employing similar mechanisms as the creation of the LSP251.

Although the system200reduces the number of communication channels240between the ZR controller210and the network230, the system200requires the ZR controller210to establish the communication channels240with all edge nodes221. In order to support communication with the ZR controller210, all edge nodes221are required to be updated to programmable network devices.

Disclosed herein are various embodiments of an efficient and flexible ZR-X scheme. The ZR-X scheme enables a user or a network administrator to configure a ZR controller to establish x number of controller-network communication channels with x number of suitable nodes in a network, where x is any positive integer. The nodes that are in direct communication with the ZR controller are referred to as communication nodes. In contrast to the system200, the communication nodes correspond to less than all the edge nodes in the network and the communication nodes may include edge nodes and/or internal nodes of the network. The ZR controller computes paths for LSPs in the network and maintains information and states associated with the LSPs. The ZR controller sends LSP creation request messages to the communication nodes, which forward the LSP creation request messages to corresponding egress nodes of the LSP. The egress nodes of the LSPs initiate creation of the LSP along upstream nodes of the LSP. The ingress nodes of the LSPs send LSP creation response messages to the ZR controller via the communication nodes that are closest to corresponding ingress nodes. Thus, label distribution protocols such as LDP and RSVP are not employed by any node in the network. In an embodiment, each node in the network comprises a routing information base that indicates forwarding paths to the network controller via a communication node and to other nodes in the network. To prevent the network controller from participating in data traffic forwarding, the cost of the paths to the network controller are set to a maximum value or a value greater than rest of the paths to the other nodes in the network. The disclosed embodiments provide several benefits such as low complexity in controller-node operations, simple controller implementations, easy scalability to support a large-scale network, simple migration with little or no service interruption, and low packet overhead. In addition, the disclosed embodiments are suitable for creating and deleting point-to-multipoint (P2MP) LSPs.

FIG. 3is a schematic diagram of a ZR-1 system300according to an embodiment of the disclosure. In contrast to the system200, the system300employs a single communication channel340for network control and management instead of multiple communication channels240to all edge nodes221. The system300comprises a ZR controller310similar to the ZR controller210communicatively coupled to a network330similar to networks130and230via the single communication channel340similar to the communication channels140and240. The network330comprises a plurality of edge nodes321, shown as PE1, PE2, PE3, and PE4, and a plurality of internal nodes322, shown as P1, P2, P3, and P4. The edge nodes321are similar to the edge nodes121and221, but only a single edge node PE2321is in direct communication with the ZR controller310via the communication channel340. Thus, the edge node PE2321functions as a single communication node in the network330. The internal nodes322are similar to the internal nodes122and222. Similar to the network220, the ZR controller310computes shortest paths for LSPs in the network330according to certain constraints and maintains information and states associated with the LSPs. However, the ZR controller310communicates with the communication node (e.g., PE2321) for all LSP creations and deletions.

As an example, the ZR controller310computes a shortest path for an LSP351across the network330. The LSP351begins at the edge node PE1321, traverses through the internal nodes P1and P2322, and ends at the edge node PE4321. To create the LSP351, the ZR controller310sends an LSP creation instruction to the edge node PE2321corresponding to the communication node in the network330via the communication channel340. The edge node PE2321forwards the LSP creation instruction to the edge node PE4321corresponding to an egress node of the LSP351via a network path361, which may comprise one or more hops or links such as the links131. The edge node PE4321initiates creation of the LSP351along the path of the LSP351.

When the creation of the LSP351is completed, the edge node PE1321corresponding to an ingress node of the LSP351sends an LSP creation status to the ZR controller310. For example, the edge node PE1321comprises an RIB that includes a route to the ZR controller310through the internal node P4322. The internal node P4322comprises an RIB that includes a route to the ZR controller310through the edge node PE2321. Thus, the edge node PE1321sends the LSP creation status to the edge node PE2321along the network path362. Subsequently, the edge node PE2321forwards the LSP creation status to the ZR controller310via the communication channel340. The LSP351may be deleted by employing similar mechanisms as the creation of the LSP351. The creation and deletion of LSPs are described more fully below. It should be noted that the edge nodes321and the internal nodes322do not employ any label distribution protocol and do not maintain LSP states. In addition, each edge node321may comprise a RIB that includes a route to the ZR controller310, but the ZR controller310is excluded from data forwarding functions, as described more fully below.

FIG. 4is a schematic diagram of a ZR-1 system400according to another embodiment of the disclosure. The system400is similar to the system300, but employs a single communication channel440between a ZR controller410and an internal node422of a network430instead of an edge node421of the network430. The ZR controller410is similar to the ZR controllers210and310. The network430is similar to the networks130,230, and330. The edge nodes421are similar to the edge nodes121,221, and321and the internal nodes422are similar to the internal nodes122,222, and322. However, only a single internal node P3422is in direct communication with the ZR controller410. The communication channel440is similar to the communication channels140,240, and340. The creation and deletion of an LSP451from the edge node PE1421to the edge node PE4421are similar to the LSP351. However, the ZR controller410sends LSP creation and deletion instructions to the internal node P3422corresponding to a communication node in the network430. The internal node P3422forwards the LSP creation and deletion instructions to the edge node PE4421corresponding to an egress node of the LSP451via a network path461similar to the network paths361and362. Upon completion of an LSP creation or deletion, the edge node PE1421corresponding to an ingress node of the LSP451sends a status to the ZR controller410via the internal node P3422along a network path462similar to the network paths361,362, and461.

FIG. 5is a schematic diagram of an embodiment of a ZR-X system500according to an embodiment of the disclosure. The system500is similar to the systems300and400, but employs x number of communication channels540to control and manage a network530, where x may be any positive integer number. For illustration purposes, the system500comprises two communication channels540, where x equals to 2. As shown, the system500comprises a ZR controller510in data communication with an edge node521and an internal node522in the network530via the communication channels540. The ZR controller510is similar to the SDN controller110and the ZR controllers210,310, and410. The network530is similar to the networks130,230,330, and430. The edge nodes521are similar to the edge nodes121,221,321, and421. The internal nodes522are similar to the internal nodes122,222,322, and422. The communication channels540are similar to the communication channels140,240,340, and440. The creation and deletion of an LSP551from the edge node PE1521to the edge node PE4521are similar to the LSPs351and451. However, the ZR controller510selects a communication node that is a next-hop node of the shortest route to the edge node PE4521corresponding to an egress node of the LSP551. For example, the internal node P3522is a node closest to the edge node PE4521among all communication nodes. A closest node refers to a node through which the path from the ZR controller510to a destination node has a shortest distance. Thus, the ZR controller510sends LSP creation and deletion instructions to the internal node P3522. Subsequently, the internal node P3522forwards the LSP creation and deletion instructions to the edge node PE4521via a network path561similar to the network paths361,362,461, and462. When the creation or deletion of the LSP551is completed, the edge node PE1521corresponding to an ingress node of the LSP551sends a status to the ZR controller510. The edge node PE1521looks up an RIB for a shortest route to the ZR controller510. For example, the edge node PE2521is a node that is closest to the edge node PE1521among all communication nodes in the network530. Thus, the route may include a network path562similar to the network paths361,362,461,462, and561to the edge node PE2521. Subsequently, the edge node PE2521forwards the status to the ZR controller510via a corresponding communication channel540. The creation and deletion of LSPs are described more fully below.

In an embodiment, each edge node521comprises an RIB that identifies routes to reach every other edge nodes521, the internal nodes522, and the ZR controller510. The routes to the ZR controller510traverse one of the communication nodes, which may be the edge node PE2521or the internal node P3522. In order to prevent the ZR controller510from participating in data forwarding functions in the network530, the segment of the routes between the ZR controller510and the communication nodes corresponding to the communication channels540are configured with a maximum path cost. Thus, the routes to the ZR controller510are automatically excluded during data forwarding.

In contrast to the system200, the system500allows the number of communication channels540to the network530to be configurable. In addition, the ZR controller510may establish the communication channels540with any nodes, which may include an edge node521and/or an internal node522in the network530, but not all edge nodes521as in the system200. For example, a user or a network administrator may configure the number of communication channels540and select suitable nodes in the network530as communication nodes. It should be noted that the system500may be configured as shown or alternatively configured as determined by a person of ordinary skill in the art to achieve similar functionalities.

FIG. 6is a schematic diagram of an embodiment of an NE600, such as ZR controllers310,410, and510, the edge nodes321,421, and521, and the internal nodes322,422, and522in the systems300,400, and500according to an embodiment of the disclosure. NE600may be configured to implement and/or support the zone routing mechanisms and schemes described herein. NE600may be implemented in a single node or the functionality of NE600may be implemented in a plurality of nodes. One skilled in the art will recognize that the term NE encompasses a broad range of devices of which NE600is merely an example. NE600is included for purposes of clarity of discussion, but is in no way meant to limit the application of the present disclosure to a particular NE embodiment or class of NE embodiments.

At least some of the features/methods described in the disclosure are implemented in a network apparatus or component such as an NE600. For instance, the features/methods in the disclosure may be implemented using hardware, firmware, and/or software installed to run on hardware. The NE600is any device that transports packets through a network, e.g., a switch, router, bridge, server, a client, etc. As shown inFIG. 6, the NE600comprises transceivers (Tx/Rx)610, which may be transmitters, receivers, or combinations thereof. The Tx/Rx610is coupled to a plurality of ports620for transmitting and/or receiving frames from other nodes.

A processor630is coupled to each Tx/Rx610to process the frames and/or determine which nodes to send the frames to. The processor630may comprise one or more multi-core processors and/or memory devices632, which may function as data stores, buffers, etc. The processor630may be implemented as a general processor or may be part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs).

The processor630comprises a ZR-X module633, which may perform path computation, network control, data forwarding, LSP creations, LSP deletions, and LSP states maintenance depending on the embodiments and may implement methods800,900,1000,1100,1200,1300,1400,1500,1600, and1700, as discussed more fully below, and/or any other flowcharts, schemes, and methods discussed herein. As such, the inclusion of the ZR-X module633and associated methods and systems provide improvements to the functionality of the NE600. Further, the ZR-X module633effects a transformation of a particular article (e.g., the network) to a different state. In an alternative embodiment, the ZR-X module633may be implemented as instructions stored in the memory devices632, which may be executed by the processor630.

The memory device632may comprise a cache for temporarily storing content, e.g., a random-access memory (RAM). Additionally, the memory device632may comprise a long-term storage for storing content relatively longer, e.g., a read-only memory (ROM). For instance, the cache and the long-term storage may include dynamic RAMs (DRAMs), solid-state drives (SSDs), hard disks, or combinations thereof. The memory device632may be configured to store one or more databases (DBs)634associated with ZR-X such as RIBS, forwarding information bases (FIBs), and LSP databases (LSPDBs), as described more fully below.

FIG. 7is a schematic diagram of a ZR controller700according to an embodiment of the disclosure. The ZR controller700is employed by the systems300,400, and500. The ZR controller700is similar to the ZR controllers310,410, and510and provides a more detailed view of the ZR controllers310,410, and510. The ZR controller700may be implemented using software and/or hardware and may be similar to the NE600. The ZR controller700comprises a constrained shortest path first (CSPF) computational unit711, a TE database (TEDB)712, an LSP manager713, a P2P LSP database (LSPDB)714, a P2MP LSPDB715, an RIB717, and a protocol processing unit716. The LSP manager713is coupled to the CSPF computational unit711, the P2P LSPDB714, the P2MP LSPDB715, and the protocol processing unit716. The CSPF computational unit711is coupled to the TEDB712and the RIB717.

The CSPF computational unit711is configured to compute routing paths through a network such as the networks130,230,330,430, and530based on certain constraints. The CSPF computational unit711may employ a CSPF algorithm. The TEDB712is configured to store network resource information of the network. For example, the TEDB712is stored in a memory device such as the memory device632. Some examples of network resource information includes bandwidths, delays, data rates, link types, statuses, and/or any other information associated with the network. For example, the CSPF computational unit711consults with the TEDB712when performing path computations. In some embodiments, the CSPF computational unit711and the TEDB712are located external to the ZR controller700and the TEDB712is managed by a TEDB manager. The RIB717is configured to store routes in the network. For example, the ZR controller700comprises a global topology view of the network with routes to reach every node such as the edge nodes121,221,321,421, and521and the internal nodes122,222,322,422, and522in the network.

The P2P LSPDB714is configured to store global identifiers (IDs) and path information associated with P2P LSPs such as the LSPs251,351,451, and551in the network. The P2MP LSPDB715is configured to store global IDs and path information associated with P2MP LSPs in the network. For example, the P2P LSPDB714and the P2MP LSPDB715are stored in the memory device. A P2P LSP comprises a single ingress node and a single egress node in the network, whereas a P2MP LSP comprises a single ingress node and multiple egress nodes in the network zone. Each P2P LSP or P2MP LSP in the network is identified by a unique global ID. In an embodiment, the P2P LSPDB714reserves a first range of global IDs for P2P LSP allocations and the P2MP LSPDB715reserves a second range of global IDs for P2MP LSP allocations, where the first range and the second range of global IDs are non-overlapping global IDs. When a global ID is allocated to a particular P2P LSP or P2MP LSP, the path information associated with the particular P2P LSP is stored in the P2P LSPDB714or the P2MP LSPDB715, respectively. The path information includes a node sequence for the LSP, a path state of the LSP, and network resources reserved for the LSP. For example, a node sequence for the LSP551is stored in the form of {PE4←P2←P1←PE1} to indicate that the LSP551traverses from the edge node PE1521, followed by the internal nodes P1and P2522, and to the edge node PE4521. In some embodiments, the P2P LSPDB714and/or the P2MP LSPDB715are located externally from the ZR controller710and are managed by an LSPDB manager.

The protocol processing unit716is configured to communicate with communication nodes such as the edge node PE2321in the system300, the internal node P3422in the system400, and the edge node PE2521and the internal node P3522in the system500. For example, the protocol processing unit716may implement an interior gateway protocol (IGP) or a border gateway protocol (BGP) with extensions, as discussed more fully below.

The LSP manager713is configured to manage and control P2P LSPs and P2M LSPs in the network. The LSP manager713coordinates with the CSPF computational unit711to compute paths through the network, for example, based on requests from users and/or applications. The LSP manager713obtains or allocates global IDs from the P2P LSPDB714for P2P LSPs. The LSP manager713obtains or allocates global IDs from the P2MP LSPDB715for P2MP LSPs. The LSP manager713communicates with the communication nodes of the network via the protocol processing unit716to create and/or delete LSPs. To create and/or delete an LSP, the LSP manager713sends a request to a communication node closest to an egress node of the LSP and receives a response from an ingress node of the LSP via a communication node closest to the ingress node. An LSP creation and/or deletion request includes a global ID of an LSP, a node sequence in the LSP, and/or other path information associated with the LSP. An LSP creation and/or deletion response includes a global ID of an LSP and a state of the LSP. When LSPs are created and/or deleted in the network, the LSP manager713tracks and maintains global IDs, statuses, and/or states of the LSPs.

FIG. 8is a protocol diagram of an embodiment of method800for creating a P2P LSP such as the LSPs351,451, and551in a ZR system such as the systems300,400, and500. The method800is implemented between a ZR controller, a first communication node of the network, an egress node PE4of an LSP, a transit node P1of the LSP, an ingress node PE1of the LSP, and a second communication node of the network. The ZR controller is similar to the ZR controllers310,410,510, and700. The first and second communication nodes are in direct association or communication with the ZR controller via communication channels similar to the communication channels140,240,340,440, and540. For example, the first and the second communication nodes correspond to the edge nodes PE2321and521and the internal nodes P3422and522. The method800is implemented when the ZR controller receives an LSP request from a user or an application. For example, the user or the application requests an LSP for forwarding a data flow or a traffic class, which may be represented by an FEC or an interface index. At step805, the ZR controller obtains a path for the LSP. The path traverses from the ingress node PE1to the egress node PE4through the transit node P1(e.g., {PE4←P1←PE1}). For example, the path is computed by a CSPF computational unit such as the CSPF computational unit711of the ZR controller. After obtaining the path, the ZR controller obtains a global ID (e.g., LSP-ID) for the LSP. For example, the global ID is allocated from a P2P LSPDB such as the P2P LSPDB714.

At step810, the ZR controller determines that the first communication node is a next-hop node or a closest node to the egress node PE4among all communication nodes. For example, the ZR controller selects the first communication node based on routing information stored in an RIB such as the RIB717. At step815, the ZR controller sends a first LSP creation request to the first communication node. The first LSP creation request includes the LSP-ID, a node sequence along the path of the LSP, which may be represented by {PE4←P1←PE1}, the LSP traffic class, and the ZR controller address. At step820, upon receiving the first LSP creation request, the first communication node determines that it is not the egress node PE4. At step825, the first communication node forwards the first LSP creation request to the egress node PE4.

At step830, upon receiving the first LSP creation request, the egress node PE4allocates a local label (e.g., L4), records the local label under the LSP-ID, and creates an FIB entry (e.g., (L4, pop)) to facilitate subsequent packet forwarding along the LSP. The FIB entry may be stored in local memory such as the memory device632. For example, when the egress node PE4receives a packet, the egress node PE4determines a forwarding port according to the FIB. When the packet is attached with a label L4, the egress node PE4removes the label L4and forwards the packet to the destination of the packet.

At step835, the egress node PE4sends a second LSP creation request to the transit node P1(e.g., a next upstream node along the path). The second LSP creation request includes the L4, LSP-ID, the traffic class, remaining hops in the path (e.g., {P1←PE1}), the LSP traffic class, and the ZR controller address. The egress node PE4may store the second LSP creation request in the memory until the transit node P1acknowledges the reception of the second LSP creation request.

At step840, upon receiving the second LSP creation request from the egress node PE4, the transit node P1sends a first acknowledgement to the egress node PE4to acknowledge the reception of the second LSP creation request. At step845, upon receiving the first acknowledgement, the egress node PE4flushes the second LSP creation request from the memory.

At step850, in response to the second LSP creation request, the transit node P1allocates a local label (e.g., L1), records L1under LSP-ID, and creates an FIB entry (e.g., (L1, L4)) to facilitate subsequent packet forwarding to the egress node PE4. For example, when the transit node P1receives a packet with a label L1, the transit node P1removes the label L1, attaches a label L4to the packet, and forwards the packet to the egress node PE4.

At step855, the transit node P1sends a third LSP creation request to the ingress node PE1(e.g., a next upstream node along the path). The third LSP creation request includes L1, LSP-ID, remaining hops in the path (e.g., {PE1}), the LSP traffic class, and the ZR controller address. Similarly, the transit node P1may store the third LSP creation request in local memory until the ingress node PE1acknowledges the reception of the third LSP creation request.

At step860, upon receiving the third LSP creation request from the transit node P1, the ingress node PE1sends a second acknowledgement to the transit node P1to acknowledge the reception of the third LSP creation request. At step865, upon receiving the second acknowledgement from the ingress node PE1, the transit node P1flushes the third LSP creation request from the memory.

At step870, in response to the third LSP creation request, the ingress node PE1creates an FIB entry (e.g., traffic class, push L1) to facilitate subsequent packet forwarding to the transit node P1. For example, when the ingress node PE1receives a packet corresponding to the traffic class, the ingress node PE1pushes or attaches the label L1to the packet and forwards the packet to the transit node P1.

At step875, the ingress node PE1looks up a route for sending a response to the ZR controller. The response includes the global ID and a creation status of the LSP. For example, the route indicates the second communication node as a next-hop node. At step880, the ingress node PE1sends the response to the second communication node. At step885, the second communication node forwards the response to the ZR controller. At step890, upon receiving the response, the ZR controller updates the P2P LSPDB according to the received response.

Although the method800is illustrated with a single transit node between the egress node PE4and the ingress node PE1, the method800may be employed to create LSPs with any number of transit nodes, which perform similar operations as the transit node P1. In addition, the method800may be employed to create a P2MP LSP. To create P2MP LSP, the ZR controller sends an LSP creation request to each egress node (e.g., destination node) of the P2MP LSP. It should be noted that the first and the second acknowledgements at steps840and860and/or the flushing of the second and third LSP creation requests at steps845and865may be optional in some embodiments. In addition, the first communication node and the second communication node may be the same node. Further, the first communication node may correspond to the egress node or the ingress node. Similarly, the second communication node may correspond to the egress node or the ingress node.

FIG. 9is a protocol diagram of an embodiment of a method900for deleting a P2P LSP, such as the LSP351. The method900is implemented between a ZR controller, a first communication node of the network, an egress node PE4of an LSP, a transit node P1of the LSP, an ingress node PE1of the LSP, and a second communication node of the network. The ZR controller is similar to the ZR controllers310,410,510, and700. The first and second communication nodes are in direct communication or association with the ZR controller via communication channels similar to the communication channels140,240,340,440, and540. For example, the first and the second communication nodes correspond to the edge nodes PE2321and521and the internal nodes P3422and522. The method900is implemented after an LSP is created by employing the method800. For example, the LSP is identified by a global ID (e.g., LSP-ID) and traverses from the ingress node PE1to the egress node PE4through the transit node P1(e.g., {PE4←P1←PE1}). The egress node PE4comprises an FIB entry, (L4, pop), for data forwarding along the LSP, where L4is a local label allocated by the egress node PE4and recorded under LSP-ID. The transit node P1comprises an FIB entry, (L1, L4), for data forwarding along the LSP, where L1is a local label allocated by the transit node P1and recorded under LSP-ID. The ingress node PE1comprises an FIB entry, (traffic class, push L1), for data forwarding along the LSP. Each of the egress node PE4, the transit node P1, and the ingress node PE1may store the FIB entry, the global ID, and/or the local label in local memory such as the memory device632.

At step905, the ZR controller determines to delete the LSP based on a user request or an application request. At step910, the ZR controller determines that the first communication node is a next-hop node or a closest node to the egress node PE4among all communication nodes. For example, the ZR controller selects the first communication node based on routing information stored in an RIB such as the RIB717. At step915, the ZR controller sends a first LSP deletion request to the first communication node. The first LSP deletion request includes the global LSP-ID, a node sequence, {PE4←P1←PE1}, for the LSP, and the ZR controller address.

At step920, upon receiving the first LSP deletion request, the first communication node determines that it is not the egress node PE4. At step925, the first communication node forwards the first LSP deletion request to the egress node PE4.

At step930, upon receiving the first LSP deletion request, the egress node PE4releases L4recorded under LSP-ID and removes the FIB entry, (L4, pop). At step935, the egress node PE4sends a second LSP deletion request to the transit node P1(e.g., a next upstream node along the LSP) requesting deletion of the LSP. The second LSP deletion request includes L4, LSP-ID, and the remaining hops in the LSP (e.g., {P1←PE1}). The egress node PE4may store the second LSP deletion request in the local memory until the transit node P1acknowledges the reception of the second request.

At step940, upon receiving the second request from the egress node PE4, the transit node P1sends a first acknowledgement to the egress node PE4to acknowledge the receipt of the second LSP deletion request. At step945, upon receiving the first acknowledgement from the transit node P1, the egress node PE4may flush the second LSP deletion request from the local memory.

At step950, in response to the second LSP deletion request, the transit node P1releases L1recorded under LSP-ID and removes the FIB entry, (L1, L4). At step955, the transit node P1sends a third LSP deletion request to the ingress node PE1(e.g., a next upstream node along the LSP) requesting deletion of the LSP. The third LSP deletion request includes L1, LSP-ID, and the remaining hop in the LSP (e.g., {PE1}). Similarly, the transit node P1may store the third LSP deletion request in the local memory until the ingress node PE1acknowledges the receipt of the third LSP deletion request.

At step960, upon receiving the third LSP deletion request from the transit node P1, the ingress node PE1sends a second acknowledgement to the transit node P1to acknowledge the receipt of the third request. At step965, upon receiving the second acknowledgement from the ingress node PE1, the transit node P1may flush the third LSP deletion request from the local memory.

At step970, in response to the third LSP deletion request, the ingress node PE1deletes the FIB entry, (traffic, push L1) corresponding to the LSP-ID. At step975, the ingress node PE1looks up a route for sending a response to the ZR controller. The response includes the LSP-ID and a deletion status of the LSP. For example, the route indicates the second communication node is a next-hop node. At step980, the ingress node PE1sends the response to the second communication node. At step985, the second communication node forwards the response to the ZR controller. At step990, upon receiving the response, the ZR controller updates the P2P LSPDB according to the received response. For example, the ZR controller releases the LSP-ID back to the P2P LSPDB and deletes associated path information.

Although the method900is illustrated with a single transit node, the method900may be employed to delete LSPs with multiple transit nodes, which perform similar operations as the transit node P1. In addition, the method900may be employed to delete a P2MP LSP. To delete P2MP LSP, the ZR controller may send an LSP deletion request to each egress node (e.g., destination node) of the P2MP LSP. It should be noted that the first and the second acknowledgements at steps940and960and/or the flushing of the second and third LSP deletion requests at steps945and965may be optional in some embodiments. In addition, the first communication node and the second communication node may be the same node. Further, the first communication node may be the egress node or the ingress node. Similarly, the second communication node may be the egress node or the ingress node.

The methods800and900may be applied when the first communication node or the second communication node are connected to the ZR controller via one or more transit nodes. In one embodiment, each transit node along a shortest path between the ZR controller and first communication node functions as a relay node. For example, when a relay node receives a first LSP creation request from a previous-hop node along the shortest path, which may be the ZR controller or another node, the relay node generates a second LSP creation request according to the received first LSP creation requests (e.g., same content). The relay node sends an acknowledgement to the previous-hop node to acknowledge the reception of the first LSP creation request and sends the second LSP creation request to a next-hop node along the shortest path. In such an embodiment, each relay node flushes a previously sent LSP creation request after receiving a corresponding acknowledgement. Similarly, when the ZR controller receives an acknowledgement for a previously sent LSP creation request, the ZR controller flushes the LSP creation request. In some other embodiments, relay nodes and communication nodes do not flush LSP creation requests after receiving acknowledgements from next-hop nodes. In such embodiments, the ZR controller flushes a previously sent LSP creation request after receiving a corresponding LSP creation response. The relay nodes and the communication nodes flush LSP creation requests after previous-hop nodes flush the LSP creation requests. The relay nodes perform similar operations for LSP creation response, LSP deletion request, and LSP deletion response.

FIG. 10is a flowchart of a method1000for creating an LSP such as the LSPs251,351,451, and551according to an embodiment of the disclosure. The method1000is implemented by a network controller such as the ZR controllers310,410,510, and700and the NE600in a network such as the systems300,400, and500. The network comprises a plurality of edge nodes such as the edge nodes121,221,321,421, and521and a plurality of internal nodes such as the internal nodes122,222,322,422, and522. The network controller is coupled to one or more communication nodes in the network via one or more communication channels such as the communication channels140,240,340,440, and540. The communication nodes correspond to less than all the edge nodes in the network. The communication nodes may comprise an edge node and/or an internal node of the network. The method1000employs similar mechanisms as described in the methods800and900. The method1000begins at step1010when an LSP creation request for a data flow is received from a user or an application that employs the network for data forwarding. The data flow may be identified by a traffic class, which may be identified by an FEC or an interface index.

At step1020, a path through the network is computed. The path extends from an ingress node (e.g., PE1) of the edge nodes to an egress node (e.g., PE4) of the edge nodes. The path may traverse through one or more internal nodes (e.g., P1and P2). For example, the network controller employs a CSPF engine such as the CSPF computational unit711to compute the path. At step1030, a global ID is obtained for the LSP along the path. For example, the network controller employs an LSP manager such as the LSP manager713to allocate the global ID from an LSPDB such as the P2P LSPDB714and the P2MP LSPDB715.

At step1040, selected second path that traverses through a first communication node of the communication nodes is obtained. For example, the network controller comprises an RIB similar to the RIB717that identifies paths to reach every node in the network and the first communication node comprises a shortest path among the communication nodes from the network controller to the egress node. At step1050, an LSP creation request message is sent to the first communication node. The LSP creation request message comprises the global ID, the traffic class that describes the data flow, the network controller address (e.g., an IP address), and path information indicating a node sequence (e.g., {PE4←P2←P1←PE1}) for the path from the ingress edge node to the egress edge node. In addition, the path information may include a bandwidth reserved for each of the links such as the link131along the path. For example, the network controller employs a protocol processing unit such as the protocol processing unit716to generate the LSP creation request message.

At step1060, an LSP creation response message is received from a second of the communication nodes that is on a shortest path to the network controller from the ingress node among the communication nodes indicating a creation status of the LSP in response to the LSP creation request message sent at step1050. At step1070, the LSPDB is updated according to the LSP creation response message. For example, the LSPDB stores an entry for the global ID, which may include the global ID, path information (e.g., bandwidths and the node sequence), and a state of the LSP. It should be noted that the method1000is suitable for creating a P2P LSP or a P2MP LSP. When creating a P2MP LSP, the path computed at step1020is for a P2MP LSP and the steps of1040-1060are repeated by selecting a closest communication node to each egress node of the P2MP LSP and sending a corresponding LSP creation request message to each closest communication node. In addition, in some embodiments, the first communication node and the egress node correspond to the same node and/or the second communication node and the ingress node correspond to the same node.

FIG. 11is a flowchart of a method1100for deleting an LSP such as the LSPs251,351,451, and551according to an embodiment of the disclosure. The method1100is implemented by a network controller such as the ZR controllers310,410,510, and700and the NE600in a network such as the systems300,400, and500. The network comprises a plurality of edge nodes such as the edge nodes121,221,321,421, and521and a plurality of internal nodes such as the internal nodes122,222,322,422, and522. The network controller is coupled to one or more communication nodes in the network via one or more communication channels such as the communication channels140,240,340,440, and540. The communication nodes correspond to less than all the edge nodes in the network. The communication nodes may comprise an edge node and/or an internal node of the network. The method1100employs similar mechanisms as described in the methods800and900. The method1100is implemented after an LSP is created for a data flow by employing similar mechanisms as described in the methods800,900, and1000. For example, a global ID is allocated to the LSP, where the global ID and a list of nodes along the LSP are stored in an LSPDB such as the P2P LSPDB714and the P2MP LSPDB715. At step1110, an LSP deletion request for the data flow is received from a user or an application.

At step1120, a first of the communication nodes that is on a shortest path from the network controller to an egress node of the LSP among the communication nodes is selected. At step1130, an LSP deletion request message is sent to the first communication node. The LSP deletion request message comprises the global ID of the LSP, the list of nodes in the LSP, and the network controller address.

At step1140, an LSP deletion response message is received from a second of the communication nodes that is on a shortest path from an ingress node of the LSP to the network controller among the communication nodes.

At step1150, the LSPDB is updated according to the LSP deletion response message. For example, the global ID is released and returned to the LSPDB and information associated with the global ID is deleted from the LSPDB. It should be noted that the method1100is suitable for deleting a P2P LSP or a P2MP LSP. When deleting a P2MP LSP, the steps of1120-1130are repeated by selecting a closest communication node to each egress node of the P2MP LSP and sending a corresponding LSP deletion request message to each closest communication node. In addition, in some embodiments, the first communication node and the egress node correspond to the same node and/or the second communication node and the ingress node correspond to the same node.

FIG. 12is a flowchart of a method1200for facilitating LSP creation according to an embodiment of the disclosure. The method1200is implemented by a NE such as the NE600operating as a communication node in direct association with a network controller such as the ZR controllers310,410, and510of a network such as the systems300,400, and500. The network comprises a plurality of edge nodes such as the edge nodes121,221,321,421, and521and a plurality of internal nodes such as the internal nodes122,222,322,422, and522. The communication node may correspond to an edge node or an internal node of the network. The communication node communicates with the network controller via a communication channel such as the communication channels140,240,340,440, and540. The method1200employs similar mechanisms as described in the methods800and900. The method1200begins at step1210when an LSP creation request message is received from the network controller requesting creation of an LSP such as the LSPs251,351,451, and551. The LSP creation request message indicates an egress node of the LSP. At step1220, a determination is made that the egress node corresponds to a different node than the NE. At step1230, a path in the network to reach the egress node is identified. At step1240, the LSP creation request message is sent to the egress node according to the path to facilitate the creation of the LSP. It should be noted that the communication node may facilitate deletion of LSPs by employing similar mechanisms as the method1200.

FIG. 13is a flowchart of a method1300for facilitating LSP creation and deletion according to an embodiment of the disclosure. The method1300is implemented by a NE such as the NE600operating as a communication node in direct association with a network controller such as the ZR controllers310,410, and510of a network such as the systems300,400, and500. The network comprises a plurality of edge nodes such as the edge nodes121,221,321,421, and521and a plurality of internal nodes such as the internal nodes122,222,322,422, and522. The communication node may correspond to an edge node or an internal node of the network. The communication node communicates with the network controller via a communication channel such as the communication channels140,240,340,440, and540. The method1300employs similar mechanisms as described in the methods800and900. The method1300begins at step1310when an LSP creation response message is received from an ingress node of an LSP such as the LSPs251,351,451, and551. At step1320, the LSP creation response message is forwarded to the network controller via a corresponding communication channel.

FIG. 14is a flowchart of a method1400for creating an LSP such as the LSPs251,351,451, and551according to another embodiment of the disclosure. The method1400is implemented by an edge node such as the edge nodes321,421, and521and the NE600of a network such as the systems300,400, and500. The method1400employs similar mechanisms as described in the methods800and900. The method1400begins at step1410when a first LSP creation request message requesting creation of an LSP is received. The first LSP creation request message comprises a global ID (e.g., LSP-ID) for the LSP, a traffic class that may be forwarded along the LSP, the network controller address (e.g., an IP address), and path information for the LSP. For example, the path is represented in the form of an ordered list {PE4←P2←P1←PE1}, where PE4is an egress node of the LSP, PE1is an ingress node of the LSP, and P1and P2are transit nodes along the LSP.

At step1420, a determination is made that the edge node corresponds to the egress node of the LSP. It should be noted that when the egress node of the LSP corresponds to a different node than the edge node, the edge node employs the method1200to forward the first LSP creation request message to the egress node.

At step1430, a local label (e.g., L4) is allocated for the LSP, for example, from a local pool of labels maintained by the edge node. At step1440, the local label is recorded under the global ID. At step1450, an FIB entry is generated for the LSP. The FIB entry comprises a match condition and an action. For example, the FIB entry is in the form of (L4, pop), which instructs the egress node to perform a label pop action (e.g., label removal) when receiving a packet with a label L4. At step1460, the path information is updated, for example, by removing PE4from the node list of the path (e.g., {P2←P1←PE1}). At step1470, a second LSP creation request message is sent to a next upstream node (e.g., P2) along the LSP. The second LSP creation request message comprises the global ID, the local label, the traffic class, and the updated path information (e.g., {P2←P1←PE1}).

FIG. 15is a flowchart of a method1500for deleting an LSP such as the LSPs251,351,451, and551according to another embodiment of the disclosure. The method1500is implemented by an edge node such as the edge nodes321,421, and521and the NE600of a network such as the systems300,400, and500. The method1500employs similar mechanisms as described in the methods800and900. The method1500is implemented after an LSP is created by employing the method1400. For example, the LSP is identified by a global ID, a local label is allocated from a local pool to the LSP, and an FIB entry is created for the LSP. At step1510, a first LSP deletion request message is received from the network controller. The first path deletion request message comprises a global ID (e.g., LSP-ID) of the LSP, a list of nodes in the LSP (e.g., {PE4←P2←P1←PE1}), and a network controller address.

At step1520, a determination is made that the edge node corresponds to the egress node of the LSP. It should be noted that when the egress node of the LSP corresponds to a different node than the edge node, the edge node employs the method1200to forward the first LSP deletion request message to the egress node.

At step1530, the local label for the LSP is released. For example, the edge node looks up the local label that is previously recorded under the global ID and returns the local label to the local pool. At step1540, the record for the global ID and the local label is removed. At step1550, the FIB entry corresponding to the LSP (e.g., associated with the local label) is deleted. At step1560, the path information is updated (e.g., {P2←P1←PE1}). At step1570, a second LSP deletion request message is sent to a next upstream node (e.g., P2) along the LSP. The second LSP deletion request message comprises the global ID, the local label, and the updated path information.

FIG. 16is a flowchart of another embodiment of a method1600for creating an LSP such as the LSPs251,351,451, and551according to another embodiment of the disclosure. The method1600is implemented by an edge node such as the edge nodes321,421, and521and the NE600of a network such as the systems300,400, and500. The method1600employs similar mechanisms as described in the methods800and900. The method1600begins at step1610when an LSP creation request message is received from a next downstream node along an LSP. For example, the creation of the LSP is initiated by a network controller such as the ZR controllers310,410, and510and the LSP traverses from a first edge node (e.g., PE1) to a second edge node (e.g., PE4) through two internal nodes (e.g., P1followed by P2) of the network. Thus, the next downstream node may correspond to P1. The first LSP creation request message comprises a global ID (e.g., LSP-ID) for the LSP, a local label (e.g., L1), a traffic class (e.g., FEC or an interface index) that may be forwarded along the LSP, the network controller address (e.g., an IP address), and path information (e.g., {PE1}). At step1620, an FIB entry is generated according to the traffic class and the local label. The FIB entry comprises a match condition and an action. For example, the FIB entry is in the form of FEC/interface index, push L1, which instructs the ingress node to perform a label push action (e.g., add label L1) when receiving a packet corresponding to the traffic class indicated by FEC or the interface index. At step1630, the FIB entry is recorded under the global ID of the LSP.

At step1640, a shortest path or a route to reach a network controller is determined using a RIB. At step1650, an LSP creation response message is sent to the next-hop node along the shortest path node, where the LSP creation response message is destined to the network controller. When a network node receives the LSP creation response message, the network node determines a route or shortest path to the network controller using a RIB and sends the message to the next-hop node along the path.

FIG. 17is a flowchart of another embodiment of a method1700for deleting an LSP such as the LSPs251,351,451, and551according to another embodiment of the disclosure. The method1700is implemented by an edge node such as the edge nodes321,421, and521and the NE600of a network such as the systems300,400, and500. The method1700employs similar mechanisms as described in the methods800and900. The method1700is implemented after an LSP (e.g., {PE4←P2←P1←PE1}) is created by employing the method1600. For example, the LSP is identified by a global ID and an FIB entry is created for the LSP. At step1710, an LSP deletion request message is received from a next downstream node along the LSP. The LSP deletion request message may comprise the global ID (e.g., LSP-ID) of the LSP, path information (e.g., {PE1}), and the network controller address. At step1720, an FIB entry corresponding to the LSP is deleted. For example, the FIB entry may be found by looking up a record that stores the FIB entry under the global ID.

At step1730, a shortest path or a route to reach a network controller is determined using a RIB. At step1740, an LSP deletion response message is sent to the next-hop node along the shortest path, where the LSP deletion response message is destined to the network controller. When a network node receives the LSP deletion response message, the network node determines a route or shortest path to the network controller using a RIB and sends the message to the next-hop node along the path.

In contrast to an SR scheme, the disclosed ZR-X scheme simplifies the controller-node interactions by enabling a ZR controller such as the controllers310,410, and510to communicate with a configurable number of edge nodes such as the edge nodes321,421, and521and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530, but not with all nodes as in the system100and not with all edge nodes as in the system200. In the ZR-X scheme, a single local label may be attached to a packet to indicate a next hop instead of a stack of labels. Thus, a network or a portion of a network may be easily migrated to employ the ZR-X scheme without any hardware upgrades, service interruptions, and/or significant network architecture changes. Thus, a network that employs the ZR-X scheme may provide better scalability than a network that employs SR and the design of the ZR-X controller is simpler than an SR controller. The following table lists comparisons between SR and ZR-X:

TABLE 1Comparisons between SR and ZR-XSRZR-XSource RoutingYesNoSome Hardware Devices UpgradeYesNoExtra Data Packet OverheadLargeMinimalMulticast SupportNoYesNetwork ScalabilityLimitedHigh ScalabilityController connects to everyYesNoedge node of a networkMigrationDifficultSimpleService Interruption During MigrationYesNoController DesignComplexSimpleChange to Existing Network ArchitectureSignificantMinimal

In contrast to an MPLS network that employs a path computation element (PCE) controller, the disclosed ZR-X scheme simplifies the routing process by allowing the edge nodes321,421, and521and the internal nodes322,422, and522in a network such as the networks330,430, and530to manage and allocate local labels along an LSP tunnel such as the LSPs251,351,451, and551. In addition, a ZR-X controller such as the ZR controllers310,410, and510establishes communication channels such as the communication channels140,240,340,440, and540with any node in a network, but not all nodes of a network. Thus, the ZR controller does not write and/or delete cross connect on every node along the LSP tunnel. Thus, a network that employs ZR-X may provide better scalability than a network that employs a PCE controller and the design of the ZR-X controller is simpler than a PCE controller. The following lists comparisons between a network that employs a PCE and a network that employs ZR-X:

TABLE 2Comparisons between PCE and ZR-XPCEZR-XController manages labelYesNoresource includingallocation of labels along a tunnelController connects everyYesOnly any X numbernode in a networkof nodesin a networkController writes/deletes cross connectYesNoon every node along a tunnelNetwork ScalabilityLimitedHigh scalabilityController ComplexityComplexSimple

FIGS. 18-35illustrate various embodiments of extensions to OSPF LSA messages described in Internet Engineering Task Force (IETF) documents Request For Comments (RFC) 5250.FIG. 18is a schematic diagram of an embodiment of an OSPF opaque LSA1800. The LSA1800is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. For example, the LSA1800may be configured as part of an LSP creation request message, an LSP creation response message, an LSP deletion request message, or an LSP deletion response message, as described more fully below. The LSA1800comprises a link state (LS) age field1805, an options field1810, an LS type field1815, an LSP action field1820, an instance field1825, an advertising router field1830, a LS sequence number field1835, a LS checksum field1840, a length field1845, and TLVs field1850.

The LS age field1805is about two octets long and indicates the time in seconds since the LSA1800was originated. The options field1810is about one octet long and indicates the optional capabilities supported by a routing domain. The LS type field1815is about one octet long and may indicate the format and function of LSA1800. For example, the LSA type field1815is to a value of nine to indicate that the LS1800is a link-local opaque LSA. The LSP action field1820is about one octet long and indicates whether an LSP action is an LSP creation or an LSP deletion. The instance field1825is about three octets long and indicates an instance number of the LSA1800. For example, the instance field1825is set to a value of one to indicate a first instance of the LSA1800. The advertising router field1830is about four octets long and indicates a router ID of the LSA's1800originator. The LS sequence number field1835is about four octets long and may be incremented by a router when a new LSA is being generated and may be employed to detect LSA duplications or old LSAs. The LS checksum field1840is about two octets long and indicates the checksum for the complete contents of LSA1800. The length field1845is about two octets long and indicates the length of the LSA in bytes. The TLVs field1850may be variable in length. A TLV encoded message may include a type field that may indicate the message type, followed by a length field that may indicate the size of the message value, and a variable-sized series of octets that carry the data for the message. The TLVs field1850may comprise LSP path information, as discussed more fully below.

FIG. 19is a schematic diagram of an embodiment of an LSP-ID TLV1900. The LSP-ID TLV1900is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The LSP-ID TLV1900may be included in the TLVs1850of the LSA1800. The LSP-ID TLV1900comprises a type field1910, a length field1920, and a value field1980. The value field1980comprises an LSP-ID field1930, an M flag1941, an S flag1942, a D flag1943, an L flag1944, an N flag1945, an F flag1946, an O flag1947, and a reserved field1950.

The type field1910is about two octets long and may be set to a value of one to indicate that the LSP-ID TLV1900is an LSP-ID TLV. The length field1920is about two octets long and indicates the length of the value field1980. The LSP-ID field1930is about four octets long and indicates an LSP-ID identifying an LSP (e.g., a global ID of the LSP351). The M flag1941is about one bit long and is set to a value of one to indicate that the LSP-ID identifies a P2MP LSP. The S flag1942is about one bit long and set to a value of one to indicate that the LSP identified by the LSP-ID is set up. The D flag1943is about one bit long and set to a value of one to indicate that the LSP identified by the LSP-ID is deleted. The L flag1944is about one bit long and set to a value of one to indicate that link protection is implemented for the LSP identified by the LSP-ID. The N flag1945is about one bit long and set to a value of one to indicate that node protection is implemented for LSP identified by the LSP-ID. The F flag1946is about one bit long and set to a value of one to indicate that facility protection is implemented for the LSP identified by the LSP-ID. The O flag1947is about one bit long and set to a value of one to indicate that a one-to-one protection is available for the LSP identified by the LSP-ID. The reserved field1950is about 25 bits long and is reserved for future use.

FIG. 20is a schematic diagram of an embodiment of an IPv4 destination address TLV2000. The IPv4 destination address TLV2000is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv4 destination address TLV2000may be included in the TLVs1850of the LSA1800. The IPv4 destination address TLV2000comprises a type field2010, a length field2020, and an IPv4 address field2030. The type field2010is about two octets long and is set to a value of two to indicate that the IPv4 destination address TLV2000is an IPv4 destination address TLV. The length field2020is about two octets long and indicates a length of the IPv4 address field2030. The IPv4 address field2030is about four octets long and indicates an IPv4 address of a destination of an LSP. For example, the LSA1800may include the IPv4 destination address TLV2000to indicate the destination of the LSP such as the LSP351.

FIG. 21is a schematic diagram of an embodiment of a label TLV2100. The label TLV2100is employed by edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The label TLV2100may be included in the TLVs1850of the LSA1800. The label TLV2100comprises a type field2110, a length field2120, and a label field2130. The type field2110is about two octets long and is set to a value of three to indicate that the label TLV2100is a label TLV. The length field2120is about two octets long and indicates a length of the label field2130. The label field2130is about four octets long and indicates a local label for an LSP, such as the LSP351. For example, the local label is locally significant between two consecutive nodes along the LSP.

FIG. 22is a schematic diagram of an embodiment of a path TLV2200. The path TLV2200is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The path TLV2200may be included in the TLVs1850of the LSA1800. The path TLV2200comprises a type field2210, a length field2220, and one or more path sub-TLVs2230. The type field2210is about two octets long and is set to a value of four to indicate that the path TLV2200is a path TLV. The length field2220is about two octets long and indicates a length of the path sub-TLVs2230. The path sub-TLVs2230may be variable in length and may comprise path information, such as a node list of paths, as discussed more fully below.

FIG. 23is a schematic diagram of an embodiment of an RR TLV2300. The RR TLV2300is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The RR TLV2300may be included in the TLVs1850of the LSA1800. The RR TLV2300comprises a type field2310, a length field2320, and one or more RR sub-TLVs2330. The type field2310is about two octets long and is set to a value of five to indicate that the RR TLV2300is a RR TLV. The length field2320is about two octets long and indicates a length of the RR sub-TLVs2330. The RR sub-TLVs2330may be variable in length and may comprise a record of all the hops that the RR TLV2300has been routed through, as discussed more fully below.

FIG. 24is a schematic diagram of an embodiment of an IPv6 destination address TLV2400. The IPv6 destination address TLV2400is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv6 destination address TLV2400may be included in the TLVs1850of the LSA1800. The IPv6 destination address TLV2400comprises a type field2410, a length field2420, and an IPv6 address field2430. The type field2410is about two octets long and is set to a value of six to indicate that the IPv6 destination address TLV2400is an IPv6 destination address TLV. The length field2420is about two octets long and indicates a length of the IPv6 address field2430. The IPv6 address field2430is about sixteen octets long and indicates an IPv6 address of a destination of an LSP. For example, the LSA1800may include the IPv6 destination address TLV2400to indicate the destination of the LSP351.

FIG. 25is a schematic diagram of an embodiment of a traffic TLV2500. The traffic TLV2500is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The traffic TLV2500may be included in the TLVs1850of the LSA1800. The traffic TLV2500comprises a type field2510, a length field2520, and a traffic sub-TLVs2530. The type field2510is about two octets long and is set to a value of seven to indicate that the traffic TLV2500is a traffic TLV. The length field2520is about two octets long and indicates a length of the traffic sub-TLVs2530. The traffic sub-TLVs2530may be variable in length and comprise traffic class information, as discussed more fully below.

FIG. 26is a schematic diagram of an embodiment of an IPv4 controller TLV2600. The IPv4 controller TLV2600is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv4 controller TLV2600may be included in the TLVs1850of the LSA1800. The IPv4 controller TLV2600comprises a type field2610, a length field2620, and a controller IPv4 address field2630. The type field2610is about two octets long and is set to a value of eight to indicate that the IPv4 controller TLV2600is an IPv4 controller TLV. The length field2620is about two octets long and indicates a length of the controller IPv4 address field2630. The controller IPv4 address field2630is about four octets long and indicates an IPv4 address of the ZR controller.

FIG. 27is a schematic diagram of an embodiment of an IPv6 controller TLV2700. The IPv6 controller TLV2700is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv6 controller TLV2700may be included in the TLVs1850of the LSA1800. The IPv6 controller TLV2700comprises a type field2710, a length field2720, and a controller IPv6 address field2730. The type field2710is about two octets long and is set to a value of nine to indicate that the IPv6 controller TLV2700is an IPv6 controller TLV. The length field2720is about two octets long and indicates a length of the controller IPv6 address field2730. The controller IPv6 address field2730is about sixteen octets long and indicates an IPv6 address of the ZR controller.

FIG. 28is a schematic diagram of an embodiment of an IPv4 address path sub-TLV2800. The IPv4 address path sub-TLV2800is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv4 address path sub-TLV2800may be included in the path sub-TLVs2230of the path TLV2200. The IPv4 address path sub-TLV2800comprises a path sub-type field2810, a length field2820, and a value field2880. The value field2880comprises an IPv4 address field2830, a prefix length field2840, an L flag2851, an H flag2852, a T flag2853, and a reserved field2860.

The path sub-type field2810is about two octets long and may be set to a value of one to indicate that the IPv4 address path sub-TLV2800is an IPv4 address path sub-TLV. The length field2820is about two octets long and indicates the length of the value field2880. The IPv4 address field2830is about four octets long and indicates an IPv4 address, which may be the IPv4 address of an edge node or an internal node or an interface or a link. The prefix length field2840is about one octet long and indicates a prefix length (e.g., for a subnet). The L flag2851is about one bit long and is set to a value of one to indicate that the node identified by the IPv4 address is in a loose hop (e.g., transit nodes of an LSP). The H flag2852is about one bit long and set to a value of one to indicate that the node identified by the IPv4 address is a head of an LSP. The T flag2853is about one bit long and set to a value of one to indicate that the node identified by the IPv4 address is a tail of an LSP. The reserved field2860is about 26 bits long and is reserved for future use.

FIG. 29is a schematic diagram of an embodiment of an IPv6 address path sub-TLV2900. The IPv6 address path sub-TLV2900is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv6 address path sub-TLV2900may be included in the path sub-TLVs2230of the path TLV2200. The IPv6 address path sub-TLV2900comprises a path sub-type field2910, a length field2920, and a value field2980. The value field2980comprises an IPv6 address field2930, a prefix length field2940, an L flag2951, an H flag2952, a T flag2953, and a reserved field2960.

The path sub-type field2910is about two octets long and may be set to a value of two to indicate that the IPv6 address path sub-TLV2900is an IPv6 address path sub-TLV. The length field2920is about two octets long and indicates the length of the value field2980. The IPv6 address field2930is about sixteen octets long and indicates an IPv6 address, which may be the IPv6 address of an edge node or an internal node or an interface or a link. The prefix length field2940is about one octet long and indicates a prefix length (e.g., for a subnet). The L flag2951, the H flag2952, and the T flag2953are similar to the L flag2851, the H flag2852, and the T flag2853, respectively. The reserved field2960is about 26 bits long and is reserved for future use.

FIG. 30is a schematic diagram of an embodiment of an LSP-ID path sub-TLV3000. The LSP-ID path sub-TLV3000is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The LSP-ID path sub-TLV3000may be included in the path sub-TLVs2230of the path TLV2200. The LSP-ID path sub-TLV3000comprises a path sub-type field3010, a length field3020, and a value field3080. The value field3080comprises an LSP-ID field3030, an L flag3041, an N flag3042, an F flag3043, an O flag3044, and a reserved field3050. The path sub-type field3010is about two octets long and may be set to a value of three to indicate that the LSP-ID path sub-TLV3000is an LSP-ID path sub-TLV. The length field3020is about two octets long and indicates the length of the value field3080. The LSP-ID field3030is about four octets long and indicates a global ID of an LSP. The L flag3041, the N flag3042, the F flag3043, and the O flag3044are similar to the L flag1944, the N flag1945, the F flag1946, and the O flag1947, respectively. The reserved field3050is about 28 bits long and is reserved for future use.

FIG. 31is a schematic diagram of an embodiment of an IPv4 FEC sub-TLV3100. The IPv4 FEC sub-TLV3100is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv4 FEC sub-TLV3100may be included in the traffic sub-TLVs2530of the traffic TLV2500. The IPv4 FEC sub-TLV3100comprises a traffic sub-type field3110, a length field3120, and a value field3180. The value field3180comprises an IPv4 address field3130, a prefix length field3140, and a reserved field3150. The traffic sub-type field3110is about two octets long and may be set to a value of one to indicate that the IPv4 FEC sub-TLV3100is an IPv4 FEC sub-TLV. The length field3120is about two octets long and indicates the length of the value field3180. The IPv4 address field3130is about four octets long and indicates an IPv4 address of a network node. For example, the network node may correspond to a destination node or a destination endpoint of a data flow, where the IPv4 address with a prefix length may be employed as a match condition for data flow. The prefix length field3140is about one octet long and indicates a prefix length (e.g., for a subnet). The reserved field3150is about three octets long and is reserved for future use.

FIG. 32is a schematic diagram of an embodiment of an IPv6 FEC sub-TLV3200. The IPv6 FEC sub-TLV3200is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv6 FEC sub-TLV3200may be included in the traffic sub-TLVs2530of the traffic TLV2500. The IPv6 FEC sub-TLV3200comprises a traffic sub-type field3210, a length field3220, and a value field3280. The value field3280comprises an IPv6 address field3230, a prefix length field3240, and a reserved field3250. The traffic sub-type field3210is about two octets long and may be set to a value of two to indicate that the IPv6 FEC sub-TLV3200is an IPv6 FEC sub-TLV. The length field3220is about two octets long and indicates the length of the value field3280. The IPv6 address field3230is about sixteen octets long and indicates an IPv6 address of a network node. For example, the network node may correspond to a destination node of a data flow, where the IPv6 address with a prefix length may be employed as a match condition for data flow. The prefix length field3240is about one octet long and indicates a prefix length (e.g., for a subnet). The reserved field3250is about three octets long and is reserved for future use.

FIG. 33is a schematic diagram of an embodiment of an interface index sub-TLV3300. The interface index sub-TLV3300is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The interface index sub-TLV3300may be included in the traffic sub-TLVs2530of the traffic TLV2500. The interface index sub-TLV3300comprises a traffic sub-type field3310, a length field3320, and an interface index field3330. The traffic sub-type field3310is about two octets long and may be set to a value of three to indicate that the interface index sub-TLV3300is an interface index sub-TLV. The length field3320is about two octets long and indicates the length of the interface index field3330. The interface index field3330is about four octets long and indicates an interface index, which may be employed for identifying a particular data flow.

FIG. 34is a schematic diagram of an embodiment of an IPv4 address RR sub-TLV3400. The IPv4 address RR sub-TLV3400is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv4 address RR sub-TLV3400may be included in the RR sub-TLVs2330of the RR TLV2300. The IPv4 address RR sub-TLV3400comprises a RR sub-type field3410, a length field3420, and a value field3480. The value field3480comprises an IPv4 address field3430, a prefix length field3440, a L flag3451, an H flag3452, a T flag3453, an A flag3454, a U flag3455, and a reserved field3460.

The RR sub-type field3410is about two octets long and may be set to a value of one to indicate that the IPv4 address RR sub-TLV3400is an IPv4 address RR sub-TLV. The length field3420is about two octets long and indicates the length of the value field3480. The IPv4 address field3430, the prefix length field3440, the L flag3451, the H flag3452, and the T flag3453are similar to the IPv4 address field2830, the prefix length fields2840and2940, the L flags2851and2951, the H flags2852and2952, the T flags2853and2953, respectively. The A flag3454is about one bit long and set to a value of one to indicate that protection is available at the downstream link of the node identified by the IPv4 address. The U flag3455is about one bit long and set to a value of one to indicate that protection is in use at the downstream link of the node identified by the IPv4 address. The reserved field3460is about 19 bits long and is reserved for future use.

FIG. 35is a schematic diagram of an embodiment of an IPv6 address RR sub-TLV3500. The IPv6 address RR sub-TLV3500is employed by a ZR controller such as the ZR controllers310,410, and510, edge nodes such as the edge nodes321,421, and521, and/or internal nodes such as the internal nodes322,422, and522of a network such as the networks330,430, and530to create and delete LSPs such as the LSPs251,351,451, and551in the network. The IPv6 address RR sub-TLV3500may be included in the RR sub-TLVs2330of the RR TLV2300. The IPv6 address RR sub-TLV3500comprises a RR sub-type field3510, a length field3520, and a value field3580. The value field3580comprises an IPv6 address field3530, a prefix length field3540, an L flag3551, an H flag3552, a T flag3553, an A flag3554, a U flag3555, and a reserved field3560.

The RR sub-type field3510is about two octets long and may be set to a value of two to indicate that the IPv6 address RR sub-TLV3500is an IPv6 address RR sub-TLV. The length field3520is about two octets long and indicates the length of the value field3580. The IPv6 address field3530is similar to the IPv6 address field2930. The prefix length field3540is similar to the prefix length fields2840,2940, and3440. The L flag3551is similar to the L flags2851,2951, and3451. The H flag3552is similar to the H flags2852,2952, and3452. The T flag3553is similar to the T flags2853,2953, and3453. The A flag3554is similar to the A flag3454. The U flag3555is similar to the U flag3455. The reserved field3560is about 19 bits long and is reserved for future use.

In an embodiment, a ZR controller such as the ZR controllers310,410, and510sends a first LSA such as the LSA1800to a communication node such as the edge nodes PE2321and521and the internal nodes P3422and522to request creation or deletion of an LSP such as the LSPs251,351,451, and551. The LSA includes an LSP-ID TLV such as the LSP-ID TLV1900, an IPv4 destination TLV such as the IPv4 destination address TLV2000, a path TLV such as the path TLV2200, a traffic TLV such as the traffic TLV2500, and an IPv4 controller TLV such as the IPv4 controller TLV2600. The path TLV includes a plurality of path sub-TLVs such as the path sub-TLV2800for the IPv4 addresses of the nodes the LSP traverses. To create an LSP, the LSA indicates an LSP creation request in an LSA action field such as the LSP action field1820. To delete an LSP, the LSA indicates an LSP deletion request in an LSA action field such as the LSP action field1820.

After receiving the first LSA, the communication node sends a first acknowledgement to the controller. In addition, it sends a second LSA such as the LSA1800to a next-hop node along the route or the shortest path to a corresponding egress node of the LSP if the communication node is not the egress node. The second LSA comprises the same contents (i.e., TLVs) as the first LSA. This is called relaying an LSA. Each of the transit nodes along the route or the shortest path from the controller to the egress node of the LSP relays the LSA in the same way as the communication node. After the egress node of the LSP receives the LSA from a NE, it sends an acknowledgment to the NE. The egress node initiates the creation and/or deletion of the LSP according to the contents of the LSA received. In one embodiment, each of the nodes along the route or the shortest path from the controller to the egress node of the LSP flushes its LSA after it sends the LSA to a next-hop node and receives an acknowledgement for the LSA from the next-hop node. In another embodiment, the controller flushes its LSA for the creation and/or deletion of the LSP after receiving a response message or LSA for the status of the creation and/or deletion of the LSP. Each of the other nodes along the route or the shortest path from the controller to the egress node of the LSP flushes its LSA generated for relaying the LSA generated by the controller after receiving a flushed LSA for the LSA generated by the controller from a previous hop node along the route or the shortest path.

The egress node and other transit nodes such as the internal nodes322along the LSP sends an LSA to a next upstream node along the LSP to request creation and/or deletion of the LSP. The LSA sent by the egress node or the transit nodes are substantially similar to an LSA sent by the ZR controller, but comprises a label TLV such as the label TLV2100, and the path TLV includes addresses of a portion of the LSP (e.g., ends at the receiving node). The ingress node of the LSP sends an LSA to the ZR controller to indicate an LSP creation and/or a deletion status. The LSA sent by the ingress node comprises an LSP-ID TLV such as the LSP-ID TLV1900with an S flag such as the S flag1942set to one indicating that the LSP is set up or a D flag such as the D flag1943set to one indicating that the LSP is deleted.

The ingress node of the LSP sends a first LSA for indicating an LSP creation and/or a deletion status to a next-hop node along a route or shortest path from the ingress node to the controller. After receiving the first LSA, the next-hop node sends a first acknowledgement to its previous hop node (e.g., the ingress node) from which the LSA is received. In addition, it sends a second LSA to its next-hop node along the route or the shortest path to the controller if it is not the controller. The second LSA comprises the same contents (i.e., TLVs) as the first LSA. Each of the transit nodes along the route or the shortest path from the ingress node to the controller relays the LSA in the same way as the next-hop node. After the controller receives the LSA from a NE, it sends an acknowledgment to the NE. The controller updates the P2P LSPDB or P2MP LSPDB for the LSP according to the contents of the LSA received. In one embodiment, each of the nodes along the route or the shortest path from the ingress node of the LSP to the controller flushes its LSA for the creation and/or deletion status of the LSP or relaying an LSA for the status of the LSP after it sends the LSA to a next-hop node and receives an acknowledgement for the LSA from the next-hop node.