Patent Description:
Segment Routing (SR) is a source-based routing technique that simplifies traffic engineering and management across network domains. It removes network state information from transit routers and nodes in the network and places the path state information into packet headers at an ingress node i.e. an ingress node may prepend a header to packets that contain a list of segments, which are instructions that are executed on subsequent nodes in the network. These instructions may be forwarding instructions, such as an instruction to forward a packet to a specific destination or interface. Segment routing works either on top of a MPLS network or on an IPv6 network. In an SR-MPLS network, segments are encoded as MPLS labels. Under SRv6, a new header called a Segment Routing Header (SRH) is used. Segments in a SRH are encoded in a list of IPv6 addresses.

A Path Computation Element (PCE) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. The PCE entity is an application that can be located within a network node or component, on a server, etc. The PCE receives the path computation request from a Path Computation Client (PCC), the path computation request requesting a path initiating at the PCC. The PCE computes the path from the PCC to an egress node via an intermediate node in response to the path computation request, and assigns label information for a label switched path (LSP) from the PCC, the intermediate node, and the egress node. The PCE sets up the LSP along the computed path by transmitting the label information directly to the PCC, the intermediate node, and the egress node for storage in a Forwarding Information Base (FIB).

Path Computation Element Protocol (PCEP) defines the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCE and PCE, enabling computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics.

PCE is used to compute the SR path in the SR networks. Path Computation Element Protocol (PCEP) has been extended to support this. Reference is made to Internet Draft of PCE working group titled "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs". A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. PCECC allows the PCE to encode various Central Controller's Instructions (CCI) to be executed at the PCC.

An SR Policy is a framework that enables instantiation of an ordered list of segments on a node for implementing a source routing policy with a specific intent for traffic steering from that node. SR policy is built using any type of Segment Identifier (SID) including those associated with topological or service instructions. An SR Policy is associated with one or more candidate paths (CP). A candidate path is the unit for signaling of an SR Policy to a headend via protocols like PCEP and the SR-Policy is carried as part of a new association type encoded along with these candidate path. Reference is made to Internet Draft of PCE working group tiled "PCEP extension to support Segment Routing Policy Candidate Paths".

In the existing solutions for supporting segment routing (SR) using PCEP extensions there is no way to create a SR policy independent of candidate paths in PCEP. The SR policy created in PCEP is always defined as a collection of candidate paths. For example, the SR Policy named 'POL1' is shown below-.

An SR policy is identified by <headend, color, end-point> tuple. The headend is the node where the policy is instantiated/ implemented. The headend is specified as an IPv4 or IPv6 address and is expected to be unique in the domain. The endpoint indicates the destination of the policy. The endpoint is specified as an IPv4 or IPv6 address and is expected to be unique in the domain. The color is a <NUM>-bit numerical value that associates the SR Policy with an intent (e.g. low-latency, high bandwidth, etc.). The endpoint and the color are used to automate the steering of service or transport routes on SR Policies. The SR policy defined in the above example defines two candidate paths (CP1 and CP2) and a preference of the candidate path is used to select the best candidate path for an SR Policy. Each candidate path (CP1 and CP2) is identified by a tuple <protocol-origin, originator, discriminator>. CP1 is the active candidate path (it is valid and it has the highest preference). The two Segment-Lists of CP1 are installed as the forwarding instantiation of SR policy POL1. More details with respect to defining the SR policy in the above example can be found in the Internet Draft titled "Segment Routing Policy Architecture" of the SPRING working group. " In PCEP, the following extensions exist, referring to Internet Draft "PCEP extension to support Segment Routing Policy Candidate Paths":.

One disadvantage of always associating the SR policy creation to candidate path is that if the candidate path goes down in a network, the entire SR policy may fail, depending upon the status of other candidate paths associated with that SR policy. The current PCEP does not allow creating a SR policy independent of the candidate paths. SR policy is container information that remains constant and needs to be encoded along with each candidate path individually.

<NPL> and <NPL> specify extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves.

This summary is provided to introduce concepts related to segment routing (SR) policy instantiation via Path Communication Element Protocol (PCEP), and the same are further described below in the detailed description. This summary is not intended to identify essential features of the claimed subject matter nor is it intended for use in determining or limiting the scope of the claimed subject matter.

A main objective of the present disclosure is to provide a mechanism using PCEP to create SR policy independent of the candidate paths. Once the SR policy is created as a container, one or more candidate paths may be associated to the SR policy container without encoding the SR policy with every other candidate path newly created. Similarly, the existing candidate paths can be modified or deleted without encoding the SR policy along with each candidate path.

Another object of the present disclosure is to provide a mechanism to delete an SR policy independently of the candidate path.

The invention is defined in te claims.

In contrast to the prior-art, the main benefits according to the present disclosure is that it is no longer necessary to send all the SR policy information with every candidate path that belongs to the same SR policy. The Central Control mechanism supported in PCEP is used to create a SR policy as an empty container at the PCC independent of creating the candidate paths at the PCE. As a result, the complexity owing to sending the SR policy parameters with every candidate path is reduced and also the complexity owing to search for the availability of the SR policy that is sent with each candidate path from the PCE to the PCC, is reduced. The overall effect is that a SR policy can be created, modified and deleted independent of the candidate paths.

The various options and preferred embodiments referred to above in relation to the first implementation are also applicable in relation to the other implementations.

The same numbers are used throughout the drawings to refer like features and components.

It is to be understood that the attached drawings are for purposes of illustrating the concepts of the invention and should not be construed as a limitation to the present invention.

The following clearly describes the technical solutions in the embodiments of the present disclosure with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are merely a part rather than all of the embodiments of the present disclosure.

The invention can be implemented in numerous ways, as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or electronic communication links.

The scope of the invention is limited only by the claims.

However, it will be understood by those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, and components, modules, units and/or circuits have not been described in detail so as not to obscure the invention.

Although embodiments of the invention are not limited in this regard, discussions utilizing terms such as, for example, "processing," "computing," "calculating," "determining," "establishing", "analyzing", "checking", or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium that may store instructions to perform operations and/or processes.

Although embodiments of the invention are not limited in this regard, the terms "plurality" and "a plurality" as used herein may include, for example, "multiple" or "two or more". The terms "plurality" or "a plurality" may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

The present disclosure relates to segment routing (SR) policy instantiation via Path Computing Element Protocol (PCEP). In accordance with the embodiments of the present invention a Path Computation Element (PCE) instantiates a SR policy at the Path Computation Client. The PCE and the PCC communicate with each other using PCEP messages which are also defined in the Internet Drafts titled 'PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs' and 'PCEP extension to support Segment Routing Policy Candidate Paths'. The PCE may therefore act upon the instructions of a Central Controller or itself act as a Path Computation Element Central Controller (PCECC) using the PCEP extensions already defined.

An SR policy contains one or more candidate paths where one or more such paths can be computed via PCE. In the existing mechanism, the candidate paths instantiated by the PCE at the PCC signals additional information to map candidate paths to their SR policies. Each candidate path maps to a unique PLSP-ID (Path LSP-ID) (Path Label Switched Path-Identifier) in PCEP. The existing mechanism creates a grouping of LSPs which can be used to define associations between a set of LSPs thereby associating multiple candidate paths belonging to the same SR policy together. Further, the existing mechanism also define a PCEP Association object by defining an association type, also referred to as `SR Policy Association' specifically for associating SR candidate paths into a single SR policy.

The present disclosure is directed to provide a mechanism that allows for SR policy initiation independent of the candidate path. For an SR policy, the SR policy parameters are color and endpoint. This allows for creation of the SR policy to be instantiated and created independent of the candidate path. Thereafter, for a group of candidate paths, belonging to the same SR policy, can be instantiated. At least for the first candidate path, the SR policy parameters and an Association Type (SR Policy Association already defined in Internet Draft) is exchanged between the PCE and the PCC. For the subsequent candidate paths, only the SR policy Association ID is exchanged, and thus all the SR policy parameters are not required to be exchanged for each candidate path that is instantiated by the PCE on the PCC. One of the key advantages identified with creating the SR policy as a container independent of the candidate path is that the SR policy may be retained even if the candidate path goes down in a network. The foregoing embodiments disclose the present invention in more detail.

<FIG> illustrates a schematic diagram of a label switched network <NUM>. In Software Defined Networks (SDN), the PCE is enabled to act as a PCECC (Path Computation Element Central Controller). The label switched network <NUM> comprises of a control plane controller <NUM>, and at least one PCE <NUM> and a plurality of nodes <NUM>. In one implementation, the PCE <NUM> may act as a PCECC. In another implementation, the PCE <NUM> may be implemented in a node <NUM> and act upon instructions of the controller plane controller <NUM> in other implementation. The role of a PCE as a PCECC is known and therefore not discussed in detail in the present disclosure. The components of the label switched network <NUM> communicate with each other via optical, electrical, or wireless means. When the label switched network is a packet switched network, data traffic is transported using packets or frames along network paths or routes. The packets may be routed or switched along a TE (Traffic Engineering) LSP (Label Switched Path) established by a signaling protocol, such as MPLS or Generalized MPLS (GMPLS), based on a path computed by the PCE and/or developed by the nodes <NUM>. Nodes <NUM> are any devices or components that support transportation of the packets through the label switched network <NUM>. For example, the nodes <NUM> may include bridges, switches, routers, or various combinations of such devices. The nodes <NUM> comprise a plurality of ingress ports for receiving packets from other nodes <NUM>, logic circuitry that determines which nodes <NUM> to send the frames to, and a plurality of egress ports for transmitting frames to the other nodes <NUM>. In some embodiments, at least some of the nodes <NUM> are label switched routers (LSRs), which are configured to modify or update the labels of the packets transported in the label switched network <NUM>. In some embodiments, some of the nodes <NUM> are label edge routers (LERs). For example, the nodes <NUM> at the edges of the label switched network <NUM> are configured to insert or remove the labels of the packets transported between the label switched network <NUM> and external networks. The first node <NUM> and the last node <NUM> along a path are sometimes referred to as the source node or head end node and the destination node or tail end node, respectively. Although four nodes <NUM> are shown in the label switched network <NUM>, the label switched network <NUM> may comprise any quantity of nodes <NUM>. Additionally, the nodes <NUM> may be located in different domains in the label switched network <NUM> and may be configured to communicate across multiple domains. For example, the nodes <NUM> that correspond to different domains may exchange packets along a path that is established across multiple domains. The control plane controller <NUM> is any device configured to coordinate activities within the label switched network <NUM>, such as a Network Management System (NMS) or Operations Support System (OSS). Specifically, the control plane controller <NUM> receives routing requests from the label switched network <NUM> and returns the corresponding path information. In addition, the control plane controller <NUM> communicates with the PCE <NUM>, for instance using a PCEP, provides the PCE <NUM> with information used for path computation, receives the computed path from the PCE <NUM>, and forwards the computed path to at least one of the nodes <NUM>. The control plane controller <NUM> may be located in a component outside of the label switched network <NUM>, such as an external server, or may be located in a component within the label switched network <NUM>, such as a node <NUM>.

The PCE <NUM> is any device configured to perform all or part of the path computation for the label switched network <NUM>, e.g. based on a path computation request. Specifically, the PCE <NUM> receives the information that is used for computing a path from the control plane controller <NUM>, from the node <NUM>, or both. The PCE <NUM> then processes the information to obtain the path. For instance, the PCE <NUM> computes the path and determines the nodes <NUM> including the LSRs along the path. The PCE <NUM> may then send all or part of the computed path information to the control plane controller <NUM> or directly to at least one node <NUM>. Further, the PCE <NUM> is typically coupled to or comprises a traffic-engineering database (TED), a P2MP Path database (PDB), a P2P path database, an optical performance monitor (OPM), a physical layer constraint (PLC) information database, or combinations thereof, which may be used to compute the path. The PCE <NUM> may be located in a component outside of the label switched network <NUM>, such as an external server, or may be located in a component within the label switched network <NUM>, such as a node <NUM>.

A path computation request is sent to the PCE <NUM> by a PCC. The PCC is any client application requesting a path computation to be performed by the PCE <NUM>. The PCC may also be any network component that makes such a request, such as the control plane controller <NUM>, or any node <NUM>, such as a LSR. For instance, the PCC requests from the PCE a P2MP path or P2P path in a single domain or across multiple domains in the label switched network <NUM>. Additionally, the PCC may send the PCE <NUM> at least some of the path required information, for example via a PCEP path computation request and/or through broadcast signaling via link state advertisements (LSAs), etc..

Data packets transported between network nodes, such as the nodes <NUM>, are referred to as label switched packets, and comprises labels that are used to switch the packets along the nodes of a computed path. A path computed or given and signaled by MPLS for transporting or routing the label switched packets is referred to as a LSP. For example, the LSP is a TE LSP established using a Resource Reservation Protocol-Traffic Engineering (RSVP-TE). The LSP may be a P2P TE LSP that extends from a source node to a destination node and is unidirectional, where the packets are transported in one direction along the path, e.g., from the source node to the destination node in the label switched network <NUM>. Alternatively, the LSP may be a P2MP TE LSP, which extends from a source or root node to a plurality of destination or leaf nodes. The P2MP TE LSP may be considered as a combination of a plurality of P2P TE LSPs that share the same source node.

The description of the PCE and the PCC above are known to a person skilled in the art and does not limit the invention disclosed herein in any manner.

<FIG> is a schematic diagram of an example embodiment of a node <NUM> which may represent the PCE <NUM>, a node <NUM> that may include a PCE and a PCC, as depicted in <FIG>. In some embodiments, the node <NUM> may implement all or parts of the methods described below with respect to the PCE and the PCC disclosed herein. One skilled in the art will recognize that the term node <NUM> is included for purposes of clarity of discussion, but is in no way meant to limit the application of the present disclosure to a particular node. At least some of the features/methods described in the disclosure are implemented in a network node, apparatus, or component such as a node <NUM>. For instance, the features/methods in the disclosure are implemented using hardware, firmware, and/or software installed to run on hardware. The node <NUM> may be any device that transports data, e.g., packets, frames, flows, and/or data streams, through a network, e.g., a switch, router, bridge, server, a client, etc. As shown in <FIG>, the node <NUM> comprises transceivers (Tx/Rx) <NUM>, which are transmitters, receivers, or combinations thereof. A Tx/Rx <NUM> is coupled to a plurality of downstream ports <NUM> for transmitting and/or receiving frames from other nodes, and a Tx/Rx <NUM> is coupled to a plurality of upstream ports <NUM> for transmitting and/or receiving frames from other nodes, respectively. A processor <NUM> is coupled to the Tx/Rx <NUM> to process the frames and/or determine which nodes to which to send frames. The processor <NUM> may comprise one or more multi-core processors and/or memory modules <NUM>, which functions as data stores, buffers, etc. Processor <NUM> is implemented as a general processor or is part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs). Processor <NUM> may comprises a PCE controller module (not shown), which is configured to provide PCE and SDN functionality and provide functionality to support the methods, computations, and/or communications as described herein. In an alternative embodiment, the PCE controller module (PCECC) is implemented as instructions stored in memory module <NUM>, which are executed by processor <NUM>. The memory module <NUM> comprises a cache for temporarily storing content, e.g., a Random Access Memory (RAM). Additionally, the memory module <NUM> comprises 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 includes dynamic random access memories (DRAMs), solid-state drives (SSDs), hard disks, or combinations thereof.

It is understood that by programming and/or loading executable instructions onto the node <NUM>, at least one of the processor <NUM>, the cache, and the long-term storage are changed, transforming the node <NUM> in part into a particular machine or apparatus, e.g., PCE which can instantiate SR policy independent of a candidate path in accordance with the functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and numbers of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change is preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable that will be produced in large volume is preferred to be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation is less expensive than the software implementation. Often a design is developed and tested in a software form and later transformed, by well-known design rules, to an equivalent hardware implementation in an ASIC that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions is viewed as a particular machine or apparatus.

As discussed above with respect to <FIG> which illustrates an embodiment of a label switched network, the PCE may act as a central controller, referred to as PCECC. The PCE computes pathway control information for each of the nodes and communicates the computed pathway control information to each of the nodes. In some embodiments, the PCE communicates with each of the nodes via PCEP.

In accordance with the embodiments of the present invention, a path computation request is sent to the PCE by a PCC, wherein the PCC may be any client application requesting a path computation to be performed by the PCE. The PCC may also be any network component that makes such a request, such as any of the nodes illustrated in <FIG>. The PCE computes the path (e.g. route), and determines the nodes (e.g. LSRs along the path) and sends all or part of the computed path information directly to each of the nodes along the pathway. In prior mechanism PCE initiated SR policy with a single candidate path or multiple candidate paths. During instantiation of one or more candidate paths on the PCC, the PCE needs to signal to a PCC <headend, color, end-point, originator, discriminator, preference> tuple using which the PCC can instantiate a candidate path for the SR policy identified. Thus, SR policy was always tied to the candidate paths.

In accordance with the present invention, SR policy can be created at the nodes independent of the candidate paths. In one implementation, the PCE which may act upon the instructions of a central controller, such as the Central Plane Controller in <FIG>, or act as the PCECC to create SR policy at the node(s), such as nodes <NUM> in <FIG>, as a separate container. The PCE which acts as a PCECC may employ existing PCECC techniques to implement the claimed embodiments of the present invention. To this end, a new Central Controller Instruction (CCI) object type is proposed within the PCECC extensions that are to create SR policy in accordance with the teachings of the present disclosure. It is to be understood that each CCI is identified by a unique identifier, referred to as CC-ID, in PCEP. By way of an example, the Internet Draft, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs" defines a PCEP object, CCI for the encoding of the CCI limited to Label forwarding instructions which is known by its own CC-ID. In order to create SR policy independent of the candidate paths, the present invention discloses new CCI object-types for a CCI to create SR policy in such a manner which is independent of the candidate paths.

The CCI object-types for creation of the SR policy encodes the SR policy parameters called the Policy Identifiers and optional TLVs (Type-Length-Value) that carry the SR policy name. Policy Identifiers uniquely identify the SR policy to which a given LSP belongs, within the context of the head-end. Policy Identifiers consist of: Head-end of SR Policy, Color of SR policy, End-point of SR policy, and optionally, the policy name. The optional TLV used for the CCI object-types for creation of the SR policy is SRPOLICY-POL-NAME TLV. This is defined as:.

Where 'Type' represents the Association Type= TBD3 which the Type for as understood in the art. Further, the 'Length' total length of the TLV in octets and MUST be greater than <NUM>. Policy Name: Policy name, as defined in [Internet Draft. ietf-spring-segment-routing-policy].

Thus, the present invention proposes new CCI object-types with a CC-ID that is to create SR policy at the nodes independent of the candidate path. In context of the present disclosure, the CCI object with CC-ID (X), where X is for illustration purposes only, is used by the PCE to instantiate the creation of SR policy to the PCC, where the creation of the SR policy is independent of the candidate path. The new CCI object is also referred to as a new PCEP object and is defined as Object-Class Value and CCI Object Type. The CCI object may be carried within PCEP message as described in more detail below. The CCI object disclosed herein is thus defined as:.

Where two SR Policy CCI object-types, one for IPv4 and another for IPv6 are defined as:
Where CC-ID: A PCEP-specific identifier for the CCI information. A PCE creates a CC-ID for each instruction, the value is unique within the scope of the PCE and is constant for the lifetime of a PCEP session. The values <NUM> and 0xFFFFFFFF are reserved and MUST NOT be used. In the present disclosure, for illustration purposes the CC-ID is referred to as a value X. The 'Color' can be an unsigned <NUM> bit number and the 'Head-end' and 'Endpoint' are either IPv4 or IPv6 addresses based on the CCI Object-Type. Further, 'Head-end', 'Color' and 'End-Point' are the same as SR policy parameters. The optional TLV is used to encode the existing TLV as defined above: SRPOLICY-POL-NAME TLV.

As indicated above, the CCI object is carried in a PCEP message from the PCE to the PCC. The PCEP messages are already used for Central Controller Instructions and are defined in [RFC8281]. In context of the present disclosure, the existing messages that support the functions required by a PCECC may be defined as:.

In accordance with the embodiments of the present invention, the first PCEP message, i.e., PCInitiate message, is used to carry the CCI with CC-ID (X) from the PCE to the PCC for creating the SR policy. The first PCEP message carries the CCI for creating SR policy independent of the candidate path. After the SR policy is created, the subsequent PCEP messages may be used to associate the SR policy to one or more candidate paths using an Association ID. Thereafter when a new candidate path is created only the Association ID may be exchanged in the PCEP messages without exchanging the SR policy parameters. It is important to understand here that the Internet draft "draft-ietf-pce-segment-routing-policy-cp-<NUM>" already defines the SR policy Association that allows for creation of candidate paths as subsets of a new or an existing SR policy. So, when a PCE wants to instantiate one or more candidate paths on the PCC, it needs to signal the SR policy parameters using which the PCC can instantiate a candidate path for the SR policy identified. However, the present invention does not require a SR policy to be mapped to the candidate paths by default and allows for creation of a SR policy as a container which can be later associated with one or more candidate paths using the Association ID that is chosen by the PCC when the SR policy thus created is to be allocated to those candidate paths. The Association parameters that uniquely identify the association between one or more candidate paths to the SR policy is already described in the Internet draft "draft-ietf-pce-segment-routing-policy-cp-<NUM>. To clearly distinguish for the candidate path instantiation disclosed in the Internet draft "draft-ietf-pce-segment-routing-policy-cp-<NUM>", and the SR policy instantiation independent of the candidate path disclosed in the present invention, reference shall now be made to <FIG> which illustrates PCEP messages communicated between a PCE and PCC, where the PCE may be a PCE <NUM> shown in <FIG> and the PCC may be a node <NUM> shown in <FIG>.

At step <NUM>, PCE <NUM> sends a first PCEP initiate message, PCInitiate, to the PCC <NUM>, where the first PCEP message carries the central controller instruction with CC-ID=X for creating a SR policy. The central control instructions may include the SR policy parameters. No candidate paths instantiation takes place in this step.

The PCC <NUM> receives the first PCEP initiate message from the PCE <NUM>, creates the SR policy using the SR policy parameters where the SR policy is a container independent of any candidate path.

At step <NUM>, the PCC <NUM> sends a first PCEP report message, PCRpt, to the PCE <NUM> to report the acknowledgement of the CC-ID=X and the newly created SR policy.

The steps <NUM> and step <NUM> are proposed in the present disclosure and are not present in the existing Internet Drafts as prior to this disclosure the creating of SR policy independent of the candidate path(s) was not known.

At step <NUM>, the PCE <NUM> sends a second PCEP initiate message, PCInitiate, to the PCC <NUM>. The second PCEP message is for creating a new candidate path (CP1) and includes an Association object for associating the candidate path to the created SR policy. The Association object includes the set of SR policy parameters and the SR Policy association identifier (Association ID) corresponding to the SR policy.

At step <NUM>, the PCC <NUM> sends a second PCEP report message, PCRpt, back to the PCE <NUM> to report the newly created candidate path (CP1) and includes the Association ID corresponding to the SR policy.

Subsequently, when the candidate path (CP1) is to be updated or a deleted, only the Association ID is sent from the PCE <NUM> to the PCC <NUM> and the entire set of SR policy parameters or the TLVs are not required to be sent. Further, when a new candidate path (CP2) is to be created only the SR policy association, i.e., the Association ID, is sent without sending the entire set of SR policy parameters.

As illustrated in <FIG>, at step <NUM>, the PCE <NUM> sends a PCEP update message, PCUpd, to the PCC <NUM>. Herein the update message is to update an existing candidate path (CP2). The PCEP update message includes the Association ID, referred to as SR policy association.

The illustration provided in <FIG> is only for providing clarity on the new CCI for creating SR policy independent of candidate paths, in comparison to existing Internet Drafts and does not limit the claimed invention in any manner. The concept of Association object and associating a new candidate path to a created SR Policy is known and therefore not discussed in detail henceforth.

The foregoing disclosure explains the embodiments of the present disclosure with the help of exemplary diagrams and one or more examples. However, such exemplary diagrams are provided for the illustration purpose for better understanding of the present disclosure and should not be construed as limitation on scope of the present disclosure.

<FIG> illustrates a method <NUM> performed by a Path Computation Element (PCE) using a Path Computation Element Protocol (PCEP). The PCE herein may refer to a PCE <NUM> which may act upon the instructions of a Central Controller or act as a PCECC which has been discussed in <FIG>. The PCE may also be one of the nodes <NUM> acting upon the instructions of a central controller. In present embodiments, the PCE acts as a PCECC. In accordance with an embodiment of the present invention, the method <NUM> includes step <NUM> where the PCE sends a first PCEP initiate message to a PCC, which may be a node <NUM> as described in <FIG> The first PCEP initiate message comprises a Central Controller Instruction (CCI) with a Central Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy. Herein the step <NUM> may be considered equivalent to step <NUM> illustrated in <FIG> and described above. The CCI object for creating a SR policy independent of a candidate path and having a CC-ID=X has already been described and is not repeated herein. Further, the method <NUM> includes step <NUM> where the PCE receives a first PCEP report message from the PCC upon creation of the SR policy, wherein the first PCEP report message is used to report by the PCC that the SR policy corresponding to the CC-ID (X) has been created. Herein the step <NUM> may be considered equivalent to step <NUM> illustrated in <FIG> and described above. Upon creating the SR policy as a separate container one or more candidate paths may be associated to the SR policy already created. One of the key advantages of creating a SR policy as a separate container is that even when the candidate path(s) go down in a network, the SR policy necessarily is not deleted and is retained.

Further, <FIG> illustrates a method <NUM> of creating a candidate path (CP1) in accordance with an embodiment of the present invention where the SR policy has been previously created at the PCC, the method <NUM> being performed by the PCE referred to in <FIG>. The method <NUM> includes a step <NUM> where the PCE sends to the PCC, a second PCEP initiate message to associate a candidate path (CP1) to the created SR policy, wherein the second PCEP initiate message includes a set of SR policy parameters and a SR Policy association identifier (Association ID) corresponding to the SR policy. Herein the step <NUM> can be considered equivalent to step <NUM> illustrated in <FIG> and described above. Further, the method includes step <NUM> where the PCE receives from the PCE a second PCEP report message wherein the second PCEP report message is used to report the association of the created candidate path (CP1) to the SR policy and the second PCEP report message includes the Association ID corresponding to the SR policy. The method of creating a candidate path initiated at the PCE is known from the teachings of the Internet Draft "draft-ietf-pce-segment-routing-policy-cp-<NUM>". Herein, the step <NUM> can be considered equivalent to step <NUM> illustrated in <FIG> and described above. It is important to note that the present disclosure is differentiated from said Internet Draft, as the SR policy is separate created in the method <NUM>, and the candidate path is now created and associated to the SR policy through the Association ID. Whereas, in the prior solution the candidate path was created along with sharing the SR policy parameters and the PCE did not known whether the SR policy exists or has to be created. Thus, one of the key advantages of creating the SR policy as a separate container and then associating candidate path(s) does not require to process at the PCE whether the SR policy exists or has to be created.

Further, <FIG> illustrates a method <NUM> of creating another candidate path (CP2) in accordance with an embodiment of the present invention where the SR policy has been previously created at the PCC, the method <NUM> being performed by the PCE referred to in <FIG>. Also by saying another candidate path (CP2) it is assumed that previous candidate path (CP1) exists. Both, the previous candidate path (CP1) and the another candidate path (CP2) are for the same SR policy created as disclosed with respect to method <NUM> above. The method <NUM> includes at step <NUM> sending a third PCEP initiate message to the PCC to associate another candidate path (CP2) to the created SR policy, wherein the third PCEP initiate message includes the Association ID and not the SR policy parameters. The advantage associated with this step is that after the set of SR policy parameters are shared for a candidate path (CP <NUM>) created for the first time and associated with the SR policy, they necessarily are not required to be shared again for the other candidate paths to be associated to the same SR policy. The Association ID is sent from the PCE to the PCC. The PCC uses the association ID to associate the candidate path (CP2) to the created SR policy. At step <NUM>, the PCE receives a receiving a third PCEP report message from the PCC, wherein the second PCEP report message is used to report the association of the created candidate path (CP2) to the SR policy and includes the Association ID.

In a further embodiment, the above described methods <NUM> and <NUM> further include a method <NUM> to update an existing candidate path. An existing candidate path can be updated without sharing the set of SR policy parameters by sharing only the Association ID to the existing SR policy already created. At step <NUM>, the PCE sends a PCEP update message includes sending a PCEP update message to the PCC to update the candidate path (CP1), wherein the PCEP update message includes the Association ID. Herein the method <NUM> can be considered equivalent to step <NUM> illustrated in <FIG> and described above. Likewise as shown in <FIG>, the method <NUM> may further include receiving an acknowledgement from the PCC (PCRpt) upon updating the candidate path with the SR policy association.

In accordance with a further embodiment of the present invention, the SR policy created, referred to the SR policy created by the disclosed method <NUM>, can be deleted by sharing the CC-ID=X using a fourth PCEP initiate message (PCInitiate). <FIG> illustrates a method <NUM> performed by the PCE wherein the PCE sends sending a fourth PCEP initiate message to the PCC wherein the fourth PCEP initiate message to delete the SR policy and the fourth PCEP initiate message includes the CC-ID (X).

<FIG> illustrates a method <NUM> performed by a Path Computation Client (PCC) using a Path Computation Element Protocol (PCEP). The PCC herein may refer to a node <NUM> as discussed in <FIG>. The PCC is in communication with a PCE which may act upon the instructions of a Central Controller or act as a PCECC which has been discussed in <FIG>. The PCE herein refers to the PCE that performs the methods <NUM>, <NUM>, <NUM>, <NUM> and <NUM>. In accordance with an embodiment of the present invention, the method <NUM> includes step <NUM> where the PCC receives a first PCEP initiate message from a PCE. The first PCEP initiate message comprises a Central Controller Instruction (CCI) with a Central Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy. Herein the step <NUM> may be considered equivalent to step <NUM> illustrated in <FIG> and described above. The CCI object for creating a SR policy independent of a candidate path and having a CC-ID=X has already been described and is not repeated herein. Further, the method <NUM> includes step <NUM> where the PCC sends a first PCEP report message to the PCE upon creation of the SR policy, wherein the first PCEP report message is used to report by the PCC that the SR policy corresponding to the CC-ID (X) has been created. Herein the step <NUM> may be considered equivalent to step <NUM> illustrated in <FIG> and described above. Upon creating the SR policy as a separate container one or more candidate paths may be associated to the SR policy already created. One of the key advantages of creating a SR policy as a separate container is that even when the candidate path(s) go down in a network, the SR policy necessarily is not deleted and is retained.

Further, <FIG> illustrates a method <NUM> of creating a candidate path (CP1) in accordance with an embodiment of the present invention where the SR policy has been previously created at the PCC, the method <NUM> being performed by the PCC referred to in <FIG>. The method <NUM> includes a step <NUM> where the PCC receives from the PCE, a second PCEP initiate message to associate a candidate path (CP1) to the created SR policy, wherein the second PCEP initiate message includes a set of SR policy parameters and a SR Policy association identifier (Association ID) corresponding to the SR policy. Herein the step <NUM> can be considered equivalent to step <NUM> illustrated in <FIG> and described above. Further, the method includes a step <NUM> where the PCC associates the candidate path (CP1) to the created SR policy. Further, the method includes step <NUM> where the PCC sends to the PCE a second PCEP report message wherein the second PCEP report message is used to report the association of the created candidate path (CP1) to the SR policy and the second PCEP report message includes the Association ID corresponding to the SR policy. One of the key advantages of creating the SR policy as a separate container and then associating candidate path(s) does not require to process at the PCE whether the SR policy exists or has to be created.

Further, <FIG> illustrates a method <NUM> of creating another candidate path (CP2) in accordance with an embodiment of the present invention where the SR policy has been previously created at the PCC, the method <NUM> being performed by the PCC referred to in <FIG>. Also by saying another candidate path (CP2) it is assumed that previous candidate path (CP1) exists. Both, the previous candidate path (CP1) and the another candidate path (CP2) are for the same SR policy created as disclosed with respect to method <NUM> above. The method <NUM> includes at step <NUM> of receiving a third PCEP initiate message from the PCE to associate another candidate path (CP2) to the created SR policy, wherein the third PCEP initiate message includes the Association ID and not the SR policy parameters. The advantage associated with this step is that after the set of SR policy parameters are shared for a candidate path (CP1) created for the first time and associated with the SR policy, they necessarily are not required to be shared again for the other candidate paths to be associated to the same SR policy. The Association ID is sent from the PCE to the PCC. Further, the method includes a step <NUM> where the PCC associates the another candidate path (CP2) to the created SR policy. The PCC uses the association ID to associate the candidate path (CP2) to the created SR policy. At step <NUM>, the PCC sends a third PCEP report message to the PCE, wherein the second PCEP report message is used to report the association of the created candidate path (CP2) to the SR policy and includes the Association ID.

In a further embodiment, the above described methods <NUM> and <NUM> further include a method <NUM> to update an existing candidate path. An existing candidate path can be updated without sharing the set of SR policy parameters by sharing only the Association ID to the existing SR policy already created. At step <NUM>, the PCC receives a PCEP update message from the PCE to update the candidate path (CP1), wherein the PCEP update message includes the Association ID. Herein the method <NUM> can be considered equivalent to step <NUM> illustrated in <FIG> and described above. Likewise as shown in <FIG>, the method <NUM> may further include sending an acknowledgement by the PCC (PCRpt) to the PCE upon updating the candidate path with the SR policy association. The illustrated method <NUM> may also include at step <NUM>, identifying, by the PCC, the SR policy associated with the candidate path from the Association ID and updating the candidate path (CP1) within the SR policy.

In accordance with a further embodiment of the present invention, the SR policy created, referred to the SR policy created by the disclosed method <NUM>, can be deleted by receiving the CC-ID=X using a fourth PCEP initiate message (PCInitiate) from the PCE. Fig. <NUM> illustrates a method <NUM> performed by the PCC wherein the PCC receives a fourth PCEP initiate message from the PCE wherein the fourth PCEP initiate message is to delete the SR policy and the fourth PCEP initiate message includes the CC-ID (X).

In addition to the above disclosed methods <NUM> and <NUM>, performed by the PCE and the PCC respectively, both the PCE and the PCC must indicate its support of the function described in this disclosure, i.e., the ability to support creation of a SR policy independent of a candidate path. This is done, by advertising to each other a defined capability TLV in an OPEN object. The definition of such OPEN object is known in PCECC extensions and is not described in detail. Accordingly, the method performed by the PCE may include advertising to the PCC in an open PCEP message to indicate that the PCE supports CCI for creating SR policy independent of candidate path, wherein the advertising is prior to sending the first PCEP initiate message. Similarly, the method performed by the PCC may include advertising to the PCE in an open PCEP message to indicate that the PCC supports CCI for creating SR policy independent of candidate path, wherein the advertising is prior to receiving the first PCEP initiate message.

In accordance with a further embodiment of the present invention, the apparatus and the system to support CCI for creating an SR policy independent of a candidate path is disclosed in the present invention.

Referring now to <FIG>, a Path Computation Element (PCE) <NUM> that performs based on a Path Computation Element Protocol (PCEP) is illustrated, in accordance with an embodiment of the present disclosure. The PCE herein may refer to a PCE <NUM> which may act upon the instructions of a Central Controller or act as a PCECC which has been discussed in <FIG>. The PCE may also be one of the nodes <NUM> acting upon the instructions of a central controller. In present embodiments, the PCE acts as a PCECC. Although the present disclosure is explained considering that the elements shown in <FIG>, it may be understood that the PCE <NUM> may include the elements and the functionalities disclosed for a node <NUM> disclosed in <FIG>. Further, it is understood from the present disclosure that the PCE <NUM> communicates with a Path Computation Client (PCC) using PCEP. The PCE <NUM> includes a memory <NUM> and a transceiver <NUM>. For sake of clarity and to distinguish the elements of the PCE <NUM> from that of the PCC in the present disclosure, the memory <NUM> shall be hereinafter referred to as the first memory <NUM> and the transceiver <NUM> shall be hereinafter referred to as the first transceiver <NUM>. Similarly, the PCE <NUM> may include a processor (not shown in <FIG>), as shown for the node <NUM> in <FIG>, which may be referred to as the first processor. It should be understood that the first memory <NUM> and the first transceiver <NUM> may be considered the same as the memory <NUM> and the transceiver <NUM> respectively, as explained above with respect to the node <NUM> of <FIG>. In accordance with the present embodiment, the PCE <NUM> is configured to perform the methods <NUM>, <NUM>, <NUM>, <NUM> and <NUM> described above. To this end, the first memory <NUM> is configured to store a PCEP object for a Central Controller Instruction (CCI) with a Central Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy. Further, the first transceiver <NUM> is configured to sends a first PCEP initiate message to a PCC, which may be a node <NUM> as described in <FIG> The first PCEP initiate message comprises the CCI) with the CC-ID (X) for creating a Segment Routing (SR) policy, and a set of parameters for the SR policy. Further, the transceiver <NUM> is configured to receive a first PCEP report message from the PCC upon creation of the SR policy, wherein the first PCEP report message is used to report by the PCC that the SR policy corresponding to the CC-ID (X) and the set of SR policy parameters has been created. Thus, the PCE is distinguished from the prior art as it supports creation of a SR policy independent of a candidate path. One of the key advantages of creating a SR policy as a separate container is that even when the candidate path(s) go down in a network, the SR policy necessarily is not deleted and is retained.

Further, the first transceiver <NUM> is configured to perform the functionalities disclosed with respect to the methods <NUM>-<NUM> disclosed in detail above and therefore the same is not repeated herein. The corresponding PCC which creates the SR policy upon instantiation by the PCE <NUM> is illustrated in <FIG>.

Referring now to <FIG>, a Path Computation Client (PCC) <NUM> that performs based on a Path Computation Element Protocol (PCEP) is illustrated, in accordance with an embodiment of the present disclosure. The PCC herein may refer to a node <NUM> which has been discussed in <FIG>. Although the present disclosure is explained considering that the elements shown in <FIG>, it may be understood that the PCC <NUM> may include the elements and the functionalities disclosed for a node <NUM> disclosed in <FIG>. Further, it is understood from the present disclosure that the PCE <NUM> communicates with the PCE <NUM> using PCEP. The PCE <NUM> includes a second memory <NUM>, a second transceiver <NUM> and a second processor <NUM>. The phrase 'second' used for the elements of PCC <NUM> is for the sake of clarity and to distinguish the elements of the PCC <NUM> from that of PCE <NUM> in the present disclosure. It should be understood that the second memory <NUM>, the second transceiver <NUM>, and the second processor <NUM> may be considered the same as the memory <NUM>, the transceiver <NUM> and the processor <NUM> respectively, as explained above with respect to the node <NUM> of <FIG>. In accordance with the present embodiment, the PCE <NUM> is configured to perform the methods <NUM>, <NUM>, <NUM>, <NUM> and <NUM> described above. To this end, the second memory <NUM> is configured to store a first list and a second list. The first list includes one or more segment routing (SR) policies created at the PCC independent of the candidate paths and the second list includes a one or more candidate paths and a respective SR policy Association Identifier for each of the one or more candidate paths, the SR policy Association Identifier corresponding to a SR policy in the first list. Further, the second transceiver <NUM> is configured to receive a first PCEP initiate message from the PCE <NUM> wherein the first PCEP initiate message comprises a Central Controller Instruction (CCI) with a Central Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy and a set of parameters for the SR policy. Further, the second processor <NUM> is configured to create the SR policy and store the SR policy in the first list. Upon creation of the SR policy, the second transceiver <NUM> is configured to sends a first PCEP report message to the PCE, wherein the first PCEP report message is used to report by the PCC that the SR policy corresponding to the CC-ID (X) and the set of SR policy parameters has been created. Thus, the PCC is distinguished from the prior art as it supports creation of a SR policy independent of a candidate path. One of the key advantages of creating a SR policy as a separate container is that even when the candidate path(s) go down in a network, the SR policy necessarily is not deleted and is retained.

Further, the second transceiver <NUM> is configured to perform the functionalities disclosed with respect to the methods <NUM>-<NUM> disclosed in detail above and therefore the same is not repeated herein. Upon receipt of the second PCEP initiate message at the PCC, the second processor <NUM> is configured to associate the candidate path (CP1) with the Association ID in the second list. Further, upon receipt of the PCEP update message at the PCC, the second processor <NUM> is configured to identify the SR policy associated with the candidate path from the Association ID and update the candidate path (CP1) within the SR policy. Further, upon receipt of the third PCEP initiate message the sending processor <NUM> is configured to associate the candidate path (CP2) with the Association ID in the second list. Further, upon receipt of the fourth PCEP initiate message at the PCC, the second processor <NUM> is configured to delete the SR policy from the first list. Further, upon receipt of the third PCEP initiate message the second processor <NUM> is configured to associate the candidate path (CP2) with the Association ID in the second list.

In accordance with yet another embodiment, a system <NUM> comprising a PCE <NUM> and a PCC <NUM> in communication with each other using PCEP is disclosed. In one implementation, the PCE <NUM> includes the PCE <NUM> disclosed with respect to <FIG> and the PCC <NUM> includes the PCC <NUM> disclosed with respect to <FIG>. In another implementation the PCE <NUM> and the PCC <NUM> includes the node <NUM> disclosed with respect to <FIG>. In yet another implementation the PCE <NUM> includes the PCE <NUM> disclosed with respect to <FIG> and the PCC includes a node <NUM> disclosed with respect to <FIG>. According to the present embodiment, the system <NUM> implements the method disclosed in <FIG> which enables creation of the SR policy independent of a candidate path using PCEP extensions. The functionalities of the PCE <NUM> are already defined with respect to PCE <NUM> and the functionalities of the PCC <NUM> are already defined with respect to PCC <NUM>. For example, the PCE <NUM> includes a first memory <NUM> that is configured to store a PCEP object for a Central Controller Instruction (CCI) with a Central Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy. Further, the PCE includes a first transceiver that is configured to sends a first PCEP initiate message to the PCC <NUM>. The first PCEP initiate message comprises the CCI with the CC-ID (X) for creating a Segment Routing (SR) policy, and a set of parameters for the SR policy. Further, the first transceiver is configured to receive a first PCEP report message from the PCC <NUM> upon creation of the SR policy, wherein the first PCEP report message is used to report by the PCC that the SR policy corresponding to the CC-ID (X) and the set of SR policy parameters has been created. The PCC <NUM> comprises a second memory and a second transceiver. The second memory is configured to store a first list and a second list. The first list includes one or more segment routing (SR) policies created at the PCC independent of the candidate paths and the second list includes a one or more candidate paths and a respective SR policy Association Identifier for each of the one or more candidate paths, the SR policy Association Identifier corresponding to a SR policy in the first list. Further, the second transceiver is configured to receive the first PCEP initiate message from the PCE <NUM> and to send the first PCEP report message to the PCE upon creation of the SR policy and to send the first PCEP report message to the PCE upon creation of the SR policy. The PCC <NUM> also includes a second processor configured to create the SR policy and store the SR policy in the first list. Thus, the system <NUM> including the PCE <NUM> and the PCC <NUM> distinguished from the prior art as it supports creation of a SR policy independent of a candidate path. One of the key advantages of creating a SR policy as a separate container is that even when the candidate path(s) go down in a network, the SR policy necessarily is not deleted and is retained.

In accordance with the further embodiment, the first transceiver of the PCE <NUM> is configured to perform the functionalities disclosed with respect to the first transceiver <NUM> of the PCE <NUM>. Further, the second transceiver and the second processor are configured to perform the functionalities of the second transceiver <NUM> and the second processor <NUM>, respectively, of the PCC <NUM>.

It may be clearly understood by a person skilled in the art that for the purpose of convenient and brief description, for a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

While several embodiments have been provided in the present disclosure, it should be understood that the disclosed systems and methods might be embodied in many other specific forms without departing from the scope of the present disclosure. The present examples are to be considered as illustrative and not restrictive, and the intention is not to be limited to the details given herein. For example, the various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described and illustrated in the various embodiments as discrete or separate may be combined or integrated with other systems, modules, techniques, or methods without departing from the scope of the present disclosure. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alterations are ascertainable by one skilled in the art and could be made without departing from the Scope disclosed herein.

Accordingly, the scope of protection is not limited by the description set out above but is defined by the claims that follow. Each and every claim is incorporated as further disclosure into the specification and the claims are embodiment(s) of the present disclosure. The discussion of a reference in the disclosure is not an admission that it is prior art, especially any reference that has a publication date after the priority date of this application.

Claim 1:
A method performed by a Path Computation Element, PCE, using a Path Computation Element Protocol, PCEP, comprising:
advertising to a Path Computation Client PCC in an open PCEP message to indicate that the PCE supports a Central Controller Instruction, CCI, for creating a Segment Routing, SR, policy independent of a candidate path,
sending (<NUM>) a first PCEP initiate message to the PCC, wherein the first PCEP initiate message comprises:
the CCI with a Central Controller Identifier, CC-ID, for creating the SR policy;
receiving (<NUM>) a first PCEP report message from the PCC upon creation of the SR policy, wherein the first PCEP report message is used to report by the PCC that the SR policy corresponding to the CC-ID has been created.