Creating and maintaining traffic engineered database for path computation element

An apparatus comprising a node configured to communicate with a path computation element (PCE) and a neighbor node, wherein the node is configured to send a local traffic engineering (TE) information directly to the PCE without sending the local TE information to the neighbor node. Also disclosed is a network component comprising at least one processor configured to implement a method comprising establishing a PCE protocol (PCEP) session with a PCE, and sending a TE information directly to the PCE without flooding the TE information. Also disclosed is a method comprising receiving a TE information, updating a first TE database (TED) using the TE information, and synchronizing the first TED with a second TED.

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

In Multiprotocol Label Switching (MPLS) networks and Generalized MPLS (GMPLS) networks, connection oriented packet services and virtual circuits can be established using a Traffic Engineering Database (TED) that comprises up-to-date and accurate Traffic Engineering (TE) information. Typically, a copy of the TED is created and maintained by at least some of the nodes in the network using an interior gateway protocol (IGP) with TE extension (IGP-TE). The individual nodes can use the TE information to compute their own TE Label Switched Paths (TE-LSPs). Some GMPLS networks have TE information that may be substantially complex, such as in wavelength switched optical networks (WSONs), e.g. as described by Lee et al. in Internet Engineering Task Force (IETF) document draft-bernstein-wson-impairment-info-02.txt, published March 2009, and entitled “Information Model for Impaired Optical Path Validation,” which is incorporated herein by reference as if reproduced in its entirety. In such networks, the TE information can be flooded from the nodes to a Path Computation Element (PCE), which is configured to handle such information and compute the TE paths in the network.

SUMMARY

In one embodiment, the disclosure includes an apparatus comprising a node configured to communicate with a PCE and a neighbor node, wherein the node is configured to send a local TE information directly to the PCE without sending the local TE information to the neighbor node.

In another embodiment, the disclosure includes a network component comprising at least one processor configured to implement a method comprising establishing a PCE protocol (PCEP) session with a PCE, and sending a TE information directly to the PCE without flooding the TE information.

In yet another embodiment, the disclosure includes a method comprising receiving a TE information, updating a first TED using the TE information, and synchronizing the first TED with a second TED.

DETAILED DESCRIPTION

Disclosed herein are systems and methods for distributing TE information in networks, such as MPLS or GMPLS networks. Specifically, some types of information, such as TE information, may be forwarded to at least one PCE without flooding the information to other network nodes. However, other types of information, such as topology information, may be flooded to both the PCE and the network nodes. The PCE may use the TE information to create a TED and compute the TE paths. In a first network architecture, each node may send the TE and topology information to a plurality of the PCEs associated with the nodes. In another network architecture, the nodes may send the TE and topology information to an intermediary server that in turn may forward the TE information to the PCEs. In a third network architecture, each node may send the TE and topology information to one of a plurality of PCEs, which then may share the information with each other. Regardless of the architecture, topology information may be distributed between the nodes, for instance using IGP, and may be maintained locally at the nodes. By offloading the tasks of creating and maintaining the TED from the nodes to the PCE, some of the nodes' resources may be freed and hence network efficiency may be improved.

FIG. 1illustrates one embodiment of a first network architecture100, which may be a MPLS or GMPLS network. The first network architecture100may comprise a plurality of nodes110and at least one PCE120. The nodes110and the PCE120may communicate with each other via optical, electrical, and/or wireless means. In addition, some of the nodes110, for example those at the edges of the network, may be configured to convert between signal types transmitted within the network and signal types used by external sources. The signals may be transported through the network over TE links or paths that may pass through some of the nodes110. Although six nodes110and two PCEs120are shown in the first network architecture100, the network may comprise any number of nodes110and PCEs120. In some embodiments, the network may be a wavelength division multiplexing (WDM) based network such as a WSON, which may use active or passive components and may implement WDM to transport optical signals. Accordingly, the nodes110and the PCE120may be coupled to one another using optical fibers and the TE links or paths may be referred to as lightpaths. The optical links may have some constraints or other properties, and thus in some embodiments the optical fibers be considered network elements.

In an embodiment, the PCE120may be a dedicated server in the network or located at one of the nodes110, and may be configured for TE path computation. The PCE120may comprise a traditional PCE (e.g. an entity that computes TE paths within the network), a TED server (e.g. a logical software entity that manages the TED and provides the TE information in the TED to the PCE without calculating any TE paths), or both. The PCE120may be a local PCE associated with at least one of the nodes110and may be configured to compute the TE paths, such as TE-LSPs, between the associated nodes110using the TE and/or topology information from the nodes110. The PCE120may comprise more processing power than the nodes110, which may allow the PCE120to perform more sophisticated path computation algorithms instead of the nodes110. Offloading the TE path computation from the nodes110to the dedicated PCE120may also reduce cost and free more resources in the network. The PCE120may then send the computed TE paths to the corresponding nodes110assigned to each of the TE paths. For example, in WDM based networks such as the WSON, some of the nodes110may be path computation clients (PCCs) that forward the TE information, such as routing and/or wavelength assignment (RWA) information to the PCE120. The PCE120may receive the RWA information from the nodes110and then process the information to compute the TE paths, for example by computing the routes, e.g. lightpaths, for the optical signals, and specifying the optical wavelengths that are used for each lightpath. For example, the PCE120may use the TE and topology information to compute the TE paths, for example as described by Farrel et al. in IETF document Request for Comments (RFC) 4655, published August 2006, and entitled “A Path Computation Element (PCE)-Based Architecture,” which is incorporated herein by reference as if reproduced in its entirety. The PCE120may then send all or part of the computed TE path (e.g. RWA) information to the nodes110.

In an embodiment, each node110may be aware of its link state, e.g. the state of its local links with other nodes110, and its local properties, e.g. port, bandwidth, and/or channel restrictions. The nodes110may also be configured to send their TE information to all the PCEs120associated with the nodes110, such as PCEs120that may share the same domain with the nodes110, and receive computed TE path information from the PCEs120. InFIG. 1, the dashed arrows indicate the flow of the local TE information from the nodes110to the PCE120and the solid lines indicate the connections, e.g. optical links, which may connect between the nodes110. The nodes110in the same domain in the network may send their TE information to the same PCEs120in the same domain, as shown inFIG. 1. In an embodiment, at least one of the nodes110may be a network management system, an element management system, and/or another PCE120. If the nodes110are in different domains, they may send their TE information to different PCEs120in their corresponding domains. Similarly, the nodes110may receive the computed TE path information from the PCEs120in the corresponding domain(s). In an embodiment, the nodes110may be referred to as network elements (NEs), and thus the two terms are used interchangeably herein. In an embodiment, each node110may comprise a link state data base (LSDB), which may be created and maintained by the node110using IGP. The LSDB may comprise topology information and/or information about the state of the local links of the node110, but may not comprise any TE information. The node110may use the LSDB information to forward the data in the network. On the other hand, the node110may route packets via the TE paths (e.g., TE-LSPs) assigned by the PCE120.

The TE information may comprise information used by the PCEs120but not the nodes110. In an embodiment, the TE information may comprise relatively large and/or static information. For example, the TE information may comprise information about at least some of the nodes' local properties, link states, bandwidth or wavelength constraints, and/or other information that may be used by the PCE120to compute the TE paths. In WDM based networks such as WSONs, the TE information may comprise information about node switching asymmetry structure, wavelength constraints, and information on wavelength usage per link. Such information is described by Lee et al. in IETF document draft-ietf-ccamp-wavelength-switched-framework-01.txt, published February 2009, and entitled “Framework for CMPLS and PCE Control of Wavelength Switched Optical Networks,” which is incorporated herein by reference as if reproduced in its entirety.

In contrast, the topology information may comprise information used by the PCEs120and the nodes110. In an embodiment, the topology information may comprise relatively small and/or dynamic information. For example, the topology information may comprise information about faulty nodes, bandwidth, and/or lightpath usage, and other information used by both the nodes110and the PCE120. The topology information may be flooded, e.g. distributed via IGP-TE, between the nodes110and/or the PCE120. By separating the TE information into information forwarded to the PCE120and information distributed between the nodes110, the information distribution or sharing constraints may be met and the sizes of the local TEDs, and hence storage demands in the nodes110, may be reduced. Similarly, the processing demands for local TED updates and synchronization in the nodes110may be reduced. Further, some of the nodes110may not need distributed TE information from the other nodes110, and thus may not create or maintain a local TED. Not creating or maintaining a local TED may reduce the communications demands, for instance at the network's control plane. Additionally, the central TED at the PCE120may be updated more frequently or with less delay time.

In an embodiment, at least some of the nodes110do not comprise a TED. Specifically, the nodes110may create and maintain the local LSDBs for routing and data forwarding purposes without creating and maintaining local TEDs. Creating and maintaining a local copy of the TED by each node110, for instance using IGP-TE, Open Shortest Path First-Traffic Engineering (OSPE-TE), or Intermediate System to Intermediate System-Traffic Engineering (IS-IS-TE), may not be favorable. For instance, maintaining a local TED at some of the nodes110may require the nodes110to have additional processing power, storage space, and/or allocated bandwidth. Additionally, flooding the TE information between the nodes110may cause message propagation delays and communication inefficiencies in the network. Further, in the case of WSONs, the information used for calculating lightpaths may comprise a minimum set of optical impairment data and/or optical impairment data, which may have sharing constraints. The sharing constraints of the optical impairment data may restrict the distribution of information via IGP-TE to some of the nodes110, as described by Bernstein et al. in IETF document draft-bernstein-ccamp-wson-impairments-00.txt, published October 2008, and entitled “A Framework for the Control and Measurement of Wavelength Switched Optical Networks (WSON) with Impairments,” which is incorporated herein by reference as if reproduced in its entirety. In some cases, the optical impairment data that has sharing constraints may still need to be stored in the TEDs of some of the nodes110, although doing so may increase network complexity and reduce efficiency.

Instead, the PCE120may comprise a TED, which may be created and maintained by the PCE120. Specifically, the PCE120may receive the local TE information from the nodes110and compile the TED. The TE information received from each node110may be the local TE information for that node110. Since the nodes110may not flood their local TE information to the other nodes110, the TE information received from each node110may be different. The TE information may then be used to obtain the computed TE paths. The TED at the PCE120may be updated periodically or upon demand to move toward optimum TE path computation. For instance, the nodes110may send to the PCE120their current TE information, periodically or upon request, and the TE information may be used to update the TED. In an alternative embodiment, the PCE120may create and maintain a central TED and at least some of the nodes110may also create and maintain local TEDs. As such, some TE information may be sent from the nodes110to the PCE120and used to obtain the central TED, and other TE information may be flooded between the nodes110to obtain the local TEDs.

To support the central TED at the PCE120, the PCE120may be configured for robust data handling and load sharing. The nodes110may also be configured to use procedures, mechanisms, and/or protocols for sending the TE information to the PCE120, and the PCE120may be configured to use procedures, mechanisms, and/or protocols for receiving the TE link information. In the case of multiple PCEs120in the first network architecture100, at least some the PCEs120may also be configured to share the same TED. Additionally, the nodes110may be configured to discover or find the PCE(s)120that may receive the corresponding TE information, for example using a PCE discovery procedures as described by LeRoux et al. in IETF document RFC 4674, published October 2006, and entitled “Requirements for Path Computation Element (PCE) Discovery,” which is incorporated herein by reference as if reproduced in its entirety.

Separating the information need to calculate and maintain the TE paths into TE information that is forwarded to the PCE120and topology information that is distributed between the nodes110may create additional requirements, such as the need for configuring and securing additional protocols. Further, any new protocols may need to support features similar to the IGP-TE features, such as removal of state information, reliable delivery of updates to all participants, recovery after reboots, crashes, and/or upgrades, etc. Forwarding the TE information to the PCE120and among the nodes110may also require node mechanisms to discover the PCE(s)120that may be capable of accepting direct TED updates.

FIG. 2illustrates an embodiment of a network200. The network200may be a MPLS or GMPLS network, such as a WDM network or WSON. The components of the network200may be configured similar to the corresponding components of the first network architecture100. Specifically, the network200may comprise a plurality of NEs210and a plurality of PCE servers220, which may each comprise a PCE221coupled to a TED222. The NEs210may be coupled to each other via optical, electrical, or wireless means, and at least one NE210may be coupled to one of the PCE servers220via a similar link. As such, at least some of the NEs210may communicate with the same PCE server220, which may be in the same domain, via a direct link or indirectly via the links between the NEs210. For instance, the NEs210may communicate with the PCE server220avia the links with the NE210a, which may be directly connected to the PCE server220a. Similarly, the NEs210may communicate with the PCE server220bvia the links with the NE210b, which may be directly connected to the PCE server220b. By use of the term directly connected to describe the various architectures described herein, it will be understood that the NEs210may be directly (e.g. no intervening elements) or indirectly (e.g. at least one intervening element) connected to the PCE server220, so long as no other NEs210are positioned in the communications path between the NE210and the PCE server220.

In an embodiment, the NEs210may perform data routing using IGP without maintaining local TEDs and without using IGP-TE. Specifically, each of the nodes110may comprise a routing engine211and a LSDB212, which may be used for forwarding the data using IGP. Each of the nodes110may also comprise a connection controller213, which may receive a service request from a first neighboring NE210and subsequently signal a second neighboring NE210to route or forward the data. As such, the nodes210may also forward their local TE information to the associated PCE server220, e.g. in the same domain, and obtain the assigned TE paths from the PCE server220. For instance, a first subset of the NEs210may communicate with the PCE server220aand a second subset of the NEs210may communicate with the PCE server220bto obtain the computed TE paths, which is indicated by the solid lines inFIG. 2.

The NEs210may update the TEDs222at the PCE servers220by sending status update information to the PCE servers220periodically or upon demand. For instance, the NEs210may send their local TE information updates to each of the PCE server220aand the PCE server220b, which is indicated by dashed lines inFIG. 2. The NEs210may also discover any new PCE server220, which may be added to the same domain of the NEs210in the network200, and may hence forward their entire local TE information to the new PCE server220. In some embodiments, the NEs210may also comprise local TEDs that comprise local TE information, and the NEs210may forward their entire local TE information to the new PCE server220.

FIG. 3illustrates one embodiment of a second network architecture300, which may be used for a MPLS or GMPLS network. The second network architecture300may comprise a plurality of nodes310and a plurality of PCEs320, which may be configured similar to the corresponding components of the first network architecture100. Additionally, the second network architecture300may comprise a publisher/subscriber (P/S) server330, which may act as an intermediary system between the nodes310and the PCEs320. The P/S server330may be a typical P/S server, or may be a PCE configured to act as a P/S server. In an embodiment, the P/S server330may not perform any path computation calculations when the P/S server330is a PCE. In addition, the P/S server330may be configured to receive the TE information from the nodes310and forward the information to the PCEs320. In some embodiments, the P/S server330may also receive the computed TE paths from the PCEs320and forward the TE paths to the assigned nodes310. As such, the nodes310may be the publishers of the information and the PCEs320may be the subscribers to the information or vice-versa.

The P/S functionality of the P/S server330may be provided by a general messaging oriented middleware, such as a Java Messaging Service (JMS), version 1.1, published April 2002 by Sun Microsystems, which is incorporated herein by reference as if reproduced in its entirety. Using the P/S server330as an intermediate entity between the nodes310and the PCE320may be suitable to solve network scaling issues, which may be introduced when the quantity of PCEs320in the system increases. Such problems may result from the increase in communication size between the nodes310and the PCEs320.

In an embodiment, the TE information may be routed from the node310to the PCEs320via the P/S server330using Border Gateway Protocol (BGP) route reflectors, as described by Bates et al. in IETF document RFC 4456, published April 2006, and entitled “BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP),” which is incorporated herein by reference as if reproduced in its entirety. In an alternative embodiment, the P/S server330may be located at or coupled to one of the PCEs320, and thus may communicate with the other PCEs320in a master/slave-type system architecture. In yet another embodiment, the P/S server330may also be configured as a PCE320, and thus may comprise a TED. Further, the P/S server330may be configured to communicate with any new PCE320, which may be added to the same network domain of the P/S server330, to create a TED at the new PCE320. The P/S server330may also maintain a copy of the TED of any of the PCEs320as a backup in case of communication failures. Further, to improve communication reliability, the second network architecture300may comprise a second redundant P/S server (not shown), which may be a backup to the P/S server330.

FIG. 4illustrates one embodiment of a third network architecture400, which may be used for a MPLS or GMPLS based network. The third network architecture400may comprise a plurality of nodes410and a plurality of PCEs420, which may be configured similar to the corresponding components of the first network architecture100. However, each PCE420may comprise a TED, which may comprise the TE information for less than all of the nodes. Specifically, the TE information stored at each PCE420may comprise the TE information from the nodes410that are associated with the PCE420, but not from the remaining nodes410. As such, the TEDs of the different PCEs420may comprise different TE information from different nodes410. Alternatively, the PCEs420, which may be in the same domain, may share their corresponding TE information with one another to compile and maintain complete TE information that comprise all the needed TE information from all the nodes410. In another alternative embodiment, the PCEs420may create and maintain a single TED remote from any of the PCEs and comprising all the TE information from all the nodes410within the same domain. For instance, each PCE420may receive their corresponding TE information from a subset of the nodes410. The PCEs420may then use their corresponding TE information to create and maintain the TED.

In an embodiment, the PCEs420may share their TE information using a PCEP that may be configured similar to a link state protocol. However, unlike the link state protocols, the PCEP may be used to share the information obtained from the associated nodes410. Accordingly, the PCEs420may be configured to peer with one another and use discovery mechanisms to find one another, e.g. using PCE discovery procedures similar to the nodes110. In an embodiment, if a new PCE420is added to same domain as the existing PCEs420, the new PCE420may peer with at least one of the existing PCEs420. Hence, to initialize a new TED at the new PCE420, the new PCE420may establish TED synchronization with the existing PCEs420, for instance using a plurality of link state procedures of the PCEP.

In an embodiment, control plane resilience may be needed in the third network architecture400. As such, each node410may be configured to send its TE information to at least one of a primary PCE and a secondary PCE from the PCEs420, which may be both associated with the node410. For example, in a warm standby scheme, the node410may initially send its TE information to its associated primary PCE but not to its associated secondary PCE. However, if communications fail between the node410and the primary PCE, the node410may begin sending its TE information to the secondary PCE. Alternatively, in a hot standby scheme, each node410may be configured to send its TE information each time to its associated primary PCE and secondary PCE, which may more reliably deliver information in the case of communications failure with one of the two associated PCEs.

In an embodiment, the nodes described herein may use discovery extensions that allow the nodes to obtain information about the existing PCEs in the network. For instance, the nodes may use the discovery extensions for OSPF, as described by LeRoux et al. in IETF document RFC 5088, published January 2008, and entitled “OSPF Protocol Extensions for Path Computation Element (PCE) Discovery,” which is incorporated herein by reference as if reproduced in its entirety. The nodes may also use the discovery extensions for IS-IS, as described LeRoux et al. in IETF document RFC 5089, published January 2008, and entitled “IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery,” which is incorporated herein by reference as if reproduced in its entirety.

In an embodiment, when the nodes find the existing PCEs in the network, the nodes may determine whether any of the existing PCEs are ready to receive TE information from the nodes. In an embodiment, the nodes may be directed to an intermediary system (e.g. P/S system), which may determine on behalf of the nodes whether any of the PCEs is ready to receive TE information from the nodes. By directly connected, it will be understood that the NEs210may be directly (e.g. no intervening elements) or indirectly (e.g. at least one intervening element) connected to the intermediary system, so long as no other NEs210are positioned in the communications path between the NE210and the intermediary system. Accordingly, the discovery mechanisms or extension used by the nodes may be extended or the location of the intermediary system may be configured to support PCE discovery by the nodes.

Additionally, an association may be first established between the nodes and the PCE ready to receive TE information (or with the intermediary system between the nodes and the PCE) before maintaining the TED at a PCE. The nodes may then share their TE information with the PCE, such as information about the nodes' local environment, e.g. links and node properties. The content of the TE information may be specified by general and/or technology specific information models and the format of the TE information may be determined by the specific protocols used in the network. In some embodiments, the nodes may send to the PCE a portion of their TE information, which may be based on the path computation option used in the network. For instance, in a WSON, a separate routing (R) and wavelength assignment (WA) option may be used, where the nodes may be responsible for routing and the PCE may be responsible for wavelength assignment, as described by Lee et al. in IETF document draft-lee-pce-wson-routing-wavelength-05.txt, published February 2009, and entitled “PCEP Requirements for the support of Wavelength Switched Optical Networks (WSON),” which is incorporated herein by reference as if reproduced in its entirety. As such, the nodes may only send the WSON link usage information to the PCE.

In an embodiment, to create and maintain the TED, the PCE may establish and authenticate communications with the nodes that may originate the TE information stored in the TED. The PCE may also update its TED in a timely manner using information received from the associated nodes, from peer PCEs, other network entities, or combinations thereof. Additionally, the PCE may verify the validity of the information in the TED, for instance by verifying that the information obtained from the nodes or other entities are substantially up to date. For example, using a process similar to functionality provided by IGP, the PCE may discard blocks or “chunks” of TE information when they become outdated or “aged.” Additionally, the nodes may send their TE information periodically to keep the TED up to date.

In an embodiment, any of the network architectures described herein may support a plurality of functions, which may be suitable for standardization. For instance, functions suitable for standardization may comprise a TE information model, basic PCE TED creation and maintenance procedures, and information packaging for TED creation, maintenance, and exchange. Additionally, the functions suitable for standardization may include node to PCE (or P/S) communication of TE information, interface, and protocol, such as a PCEP. Such functions may also comprise the NE or node PCE (or P/S) discovery for TED creation and maintenance purposes.

The TE information model may comprise the raw or basic information that may be used for a path computation model independent of the information packaging for TED creation, maintenance, and exchange. For example, the TE information model may include an information model for WSONs for non-impairment RWA and for impairment aware RWA. Given a TE information model and basic PCE TED creation and maintenance procedures, information packaging for TED creation, maintenance, and exchange may be standardized. The basic PCE TED creation and maintenance procedures may be configured similar to IGP database maintenance procedures, such as aging and packaging of link state information into link state advertisements (LSAs), which may comprise the basic blocks or chunks of an IGP's database. For example, the OSPF LSAs may comprise an age field, which may be used in the ageing procedure, and an advertising router field, which may aid in redistribution decisions, e.g. flooding. The OSPF LSAs may be configured as described by Berger et al. in IETF document RFC 5250, published July 2008, and entitled “The OSPF Opaque LSA Option,” which is incorporated herein by reference as if reproduced in its entirety. The LSAs may also comprise detailed TE information, which may be encoded or packaged into type-length-value (TLV) triplets and used for path computation. Further, the TE information communication interface between the NE and PCE, which may comprise NE and PCE behaviors and communications protocols, may be standardized.

In an embodiment, the functions in the network architectures that may be standardized may comprise the functions that may be used to support a new PCE in the network, such as the discovery of the new PCE and the initialization of the TED. Additionally, the functions in the network architectures that may be standardized may comprise the synchronization between a new PCE and the P/S server, and the communications between the PCEs and the P/S server. Further, the standardized functions in the network architectures may also comprise the PCE to PCE interface and protocol, the PCE to PCE discovery method for TE information sharing, and the PCE to PCE association for information sharing, such as sharing update information.

FIG. 5illustrates an embodiment of a TED synchronization process500, for instance which may be used in the network architectures described herein. Specifically, the TED synchronization process500may be performed between a node510, a first PCE server520a, and a second PCE server520b, which may be configured similar to the corresponding components of the network architectures described herein. Accordingly, the node510may send a TE information update to the first PCE server520a, the second PCE server520b, or both, which may be used to update the corresponding TED(s). For instance, the node510may send the same TE information update or different TE information updates to the first PCE server520aand the second PCE server520b. The node510may then receive a TE information update acknowledgement, which may indicate that the TE information update has been received and/or the TED has been updated. When the first PCE server520a, the second PCE server520b, or both receive the TE information update from the node510, the first PCE server510a, the second PCE server520b, or both may synchronize their corresponding TED(s) with one another, for instance using a TED synchronization procedure. As such, the TEDs at the first PCE server520aand the second PCE server520bmay be synchronized after each TE information update from the node510.

FIG. 6illustrates an embodiment of another TED synchronization process600that may be used with network architectures described herein. Specifically, the TED synchronization process600may be performed between a node610, and a plurality of PCE servers620including a first PCE server620a, a second PCE server620b, and a third PCE server620c, which may be configured based on network architectures described herein. Accordingly, the node610may send its TE information to the first PCE server620abut not to the remaining PCE servers620, which may be in the same domain. In some embodiments, the node610may also send its TE information to another PCE server in another set of PCE servers (not shown). When the first PCE server620areceives the TE information from the node610, the first PCE server620amay perform TED synchronization with the second PCE server620b, the third PCE server620c, and any other PCE server620. If one of the PCE servers620fails, for example due to a node or link failure, the other PCE servers620may be informed of the failure, for instance by the node610. As such, the PCE servers620may perform additional TED synchronization apart from the periodic or scheduled TED synchronization. Further, if the first PCE server620a, which may be configured to receive the TE information from the node610, fails due to a link or node failure, another PCE server620may be selected, for instance by the node610, to receive the TE information from the node610.

FIG. 7illustrates one embodiment of a PCE server updating and synchronization method700, which may be used in the network architectures described herein. The method700may begin at block710, where a PCE discovery procedure may be performed. For instance, a node or a NE, such as the NE210, may use a PCE discovery protocol (PCEDP) to discover at least one new or existing PCE server, such as the PCE server220, which may be configured to accept direct TE information updates from the node. In some embodiments, a first PCE server may use the PCEDP to discover at least one other PCE server when the other PCE servers are in the same domain.

The method700may then proceed to block720, where at least one PCE server may be selected for the TE information update, for instance by a node or NE. Selecting the PCE server may be based on a plurality of network factors, such as the distance or number of hops between the node and the PCE server and/or the current workload of the PCE. For instance, the PCE server may be selected based on its current workload to balance the workloads of the PCEs in the same domain. The workload of the PCE may be estimated based on a response time of a previous TE information update. The method700may then proceed to block730, where a PCEP session may be initialized. For instance, the node may establish a plurality of PCEP sessions with a plurality of corresponding PCE servers in the network. In addition, the node may associate with more than one PCE server for the TE information update. The method700may then proceed to block740, where TE information at the PCE server may be updated. For instance, the node may send is updated TE information to at least one of the selected PCE servers or to each of the PCE servers associated with the node.

The method700may then proceed to block750, where a determination may be made as to whether the selected PCE server may be unreachable. For instance, the node may determine whether the PCE server may not be reached due to a link failure. If the selected PCE server is reachable, the method700may return to block740. If the selected PCE server is unreachable, the method700may proceed to block760. Otherwise, the method700may return to block740. At block760, any remaining PCE server may be notified that the TE information source or node is active or alive. Accordingly, the remaining PCE server may expect TE information updates from the node. After block760, the method700may return to block720. If the selected PCE server remains reachable, the method700may return to block740.

The network components described above may be implemented on any general-purpose network component, such as a computer or network component with sufficient processing power, memory resources, and network throughput capability to handle the necessary workload placed upon it.FIG. 8illustrates a typical, general-purpose network component800suitable for implementing one or more embodiments of the components disclosed herein. The network component800includes a processor802(which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage804, read only memory (ROM)806, random access memory (RAM)808, input/output (I/O) devices810, and network connectivity devices812. The processor802may be implemented as one or more CPU chips, or may be part of one or more application specific integrated circuits (ASICs).

The secondary storage804is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM808is not large enough to hold all working data. Secondary storage804may be used to store programs that are loaded into RAM808when such programs are selected for execution. The ROM806is used to store instructions and perhaps data that are read during program execution. ROM806is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of secondary storage804. The RAM808is used to store volatile data and perhaps to store instructions. Access to both ROM806and RAM808is typically faster than to secondary storage804.