Patent Application
20230336471
The present disclosure described herein, in general, relates to a Software Defined Network (SDN) enabled network. In particular, the embodiments described in the present disclosure relate to system, apparatuses and methods using a Path Computation Element Protocol (PCEP).
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 Multiprotocol Label Switching (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 an 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 without the need for complete replacement. 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. An 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 paths. Reference is made to Internet Draft of PCE working group titled “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 an 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 32-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 an 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 an SR policy independent of the candidate paths. An SR policy is container information that remains constant and needs to be encoded along with each candidate path individually.
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 an SR policy independent of the candidate paths. Once the SR policy is created as a container, one or more candidate paths may be associated with 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.
Accordingly, in one implementation, the present disclosure provides a method performed by a Path Computation Element (PCE) using a Path Computation Element Protocol (PCEP). The method comprises sending a first PCEP initiate message to a Path Computation Client (PCC). The first PCEP initiate message comprises a Central Controller Instruction (CCI) with a Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy. Further, the method comprises receiving 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.
In one implementation, the PCE acts as a PCE Central Controller (PCECC).
In another implementation, a method performed by a Path Computation Client (PCC) using a Path Computation Element Protocol (PCEP) is disclosed. The method comprises receiving a first PCEP initiate message from a Path Computation Element (PCE). The first PCEP initiate message comprises a Central Controller Instruction (CCI) with a Controller Identifier (CC-ID) (X) for creating a Segment Routing (SR) policy. Further, the method comprises receiving 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.
In yet another implementation, a Path Computation Element (PCE) using a Path Computation Element Protocol (PCEP) is disclosed. The PCE comprises a first memory 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 comprises a first transceiver configured to send a first PCEP initiate message to a Path Computation Client (PCC), wherein the first PCEP initiate message comprises the CCI with the CC-ID (X) for creating an SR policy. Further, the first transceiver 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) has been created.
In yet another implementation, a Path Computation Client using a Path Computation Element Protocol (PCEP) is disclosed. The PCC comprises a second memory configured to store a first list including one or more Segment Routing (SR) policies created at the PCC independent of the candidate paths and a second list including 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 an SR policy in the first list. Further, the PCC comprises a second transceiver configured to receive a first PCEP initiate message from a Path Computation Element (PCE). The first PCEP initiate message comprises a Central Control Instruction (CCI) with a CC-ID (X) for creating an SR policy. Further, the PCC comprises a second processor configured to create the SR policy and store the SR policy in the first list. Further, the second transceiver is configured to send 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.
In yet another implementation, a system comprising a Path Computation Element (PCE) and a Path Computation Client (PCC) in communication with each other using Path Computation Element Protocol (PCEP) is disclosed. The PCE comprises a first memory 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 comprises a first transceiver configured to send a first PCEP initiate message to the PCC, wherein the first PCEP initiate message comprises the CCI with the CC-ID (X) for creating an SR policy. Further, the first transceiver 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) has been created. The PCC comprises a second memory configured to store a first list including one or more Segment Routing (SR) policies created at the PCC independent of the candidate paths and a second list including 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 an SR policy in the first list. Further, the PCE comprises a second transceiver configured to receive the first PCEP initiate message from the PCE. Further, the PCE comprises a second processor configured to create the SR policy and store the SR policy in the first list. Further, the second transceiver configured to send the first PCEP report message to the PCE upon creation of the SR policy.
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 an SR policy as an empty container at the PCC independent of creating the candidate paths at the PCE. As a result, it reduces the complexity due to sending the SR policy parameters with every candidate path as well as the complexity due to search for the availability of the SR policy that is sent with each candidate path from the PCE to the PCC. The overall effect is that an 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 detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. 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 disclosure and should not be construed as a limitation to the present disclosure.
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 present disclosure 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. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.
A detailed description of one or more embodiments of the present disclosure is provided below along with accompanying figures that illustrate the principles of the present disclosure. The present disclosure is described in connection with such embodiments, but the present disclosure is not limited to any embodiment. The scope of the present disclosure is limited only by the claims and the present disclosure encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the present disclosure. These details are provided for the purpose of example and the present disclosure may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the present disclosure has not been described in detail so that the present disclosure is not unnecessarily obscured.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. 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 present disclosure.
Although embodiments of the present disclosure 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 present disclosure 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 disclosure, a Path Computation Element (PCE) instantiates an 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 signal 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 defines 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 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 the 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.
The PCE 130 is any device configured to perform all or part of the path computation for the label switched network 110, e.g., based on a path computation request. Specifically, the PCE 130 receives the information that is used for computing a path from the control plane controller 120, from the node 112, or both. The PCE 130 then processes the information to obtain the path. For instance, the PCE 130 computes the path and determines the nodes 112 including the LSRs along the path. The PCE 130 may then send all or part of the computed path information to the control plane controller 120 or directly to at least one node 112. Further, the PCE 130 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 130 may be located in a component outside of the label switched network 110, such as an external server, or may be located in a component within the label switched network 110, such as a node 112.
A path computation request is sent to the PCE 130 by a PCC. The PCC is any client application requesting a path computation to be performed by the PCE 130. The PCC may also be any network component that makes such a request, such as the control plane controller 120, or any node 112, such as an 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 110. Additionally, the PCC may send the PCE 130 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 112, are referred to as label switched packets, and comprise 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 an 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 110. 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 is known to a person skilled in the art and does not limit the invention disclosed herein in any manner.
It is understood that by programming and/or loading executable instructions onto the node 200, at least one of the processor 230, the cache, and the long-term storage are changed, transforming the node 200 in part into a particular machine or apparatus, e.g., PCE which can instantiate an 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
In accordance with the embodiments of the present disclosure, 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
In accordance with the present disclosure, an 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
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: a Head-end of SR Policy, Color of SR policy, an 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 0. Policy Name: Policy name, as defined in [Internet Draft.ietf-spring-segment-routing-policy].
Thus, the present disclosure proposes new CCI object-types with a CC-ID that is to create the 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 an 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 an Object-Class Value and a CCI Object Type. The CCI object may be carried within a 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:
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 disclosure, the first PCEP message, i.e., a 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 an 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 with 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-00” 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 disclosure does not require an SR policy to be mapped to the candidate paths by default and allows for creation of an 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-00”, and is incorporated in the present disclosure by reference. To clearly distinguish the candidate path instantiation disclosed in the Internet draft “draft-ietf-pce-segment-routing-policy-cp-00”, over the SR policy instantiation independent of the candidate path disclosed in the present disclosure, reference shall now be made to
At step 302, PCE 130 sends a first PCEP initiate message, PCInitiate, to the PCC 112, where the first PCEP message carries the central controller instruction with CC-ID=X for creating an SR policy. The central control instructions may include the SR policy parameters. No candidate paths instantiation takes place in this step.
The PCC 112 receives the first PCEP initiate message from the PCE 130, creates the SR policy using the SR policy parameters where the SR policy is a container independent of any candidate path.
At step 304, the PCC 112 sends a first PCEP report message, PCRpt, to the PCE 130 to report the acknowledgement of the CC-ID=X and the newly created SR policy.
The steps 302 and step 304 are proposed in the present disclosure and are not present in the existing Internet Drafts as prior to this disclosure, the creating of an SR policy independent of the candidate path(s) was not known.
At step 306, the PCE 130 sends a second PCEP initiate message, PCInitiate, to the PCC 112. 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 308, the PCC 112 sends a second PCEP report message, PCRpt, back to the PCE 130 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 deleted, only the Association ID is sent from the PCE 130 to the PCC 112 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
The illustration provided in
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.
Further,
Further,
In a further embodiment, the above described methods 400 and 500 further include a method 700 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 that has already been created. At step 700, the sending of a PCEP update message by the PCE 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 700 can be considered equivalent to step 310 illustrated in
In accordance with a further embodiment of the present disclosure, the SR policy created, referred to the SR policy created by the disclosed method 400, can be deleted by sharing the CC-ID=X using a fourth PCEP initiate message (PCInitiate).
Further,
Further,
In a further embodiment, the above described methods 900 and 1000 further include a method 1200 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 that has already been created. At step 1202, 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 1202 can be considered equivalent to step 310 illustrated in
In accordance with a further embodiment of the present disclosure, the SR policy created, referred to the SR policy created by the disclosed method 900, can be deleted by receiving the CC-ID=X using a fourth PCEP initiate message (PCInitiate) from the PCE.
In addition to the above disclosed methods 400 and 900, 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 the creation of an 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 an SR policy independent of any 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 an SR policy independent of any candidate path, wherein the advertising is prior to receiving the first PCEP initiate message.
In accordance with a further embodiment of the present disclosure, the apparatus and the system to support CCI for creating an SR policy independent of a candidate path is disclosed in the present disclosure.
Referring now to
Further, the first transceiver 1404 is configured to perform the functionalities disclosed with respect to the methods 500-800 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 1400 is illustrated in
Referring now to
Further, the second transceiver 1504 is configured to perform the functionalities disclosed with respect to the methods 1000-1300 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 1506 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 1506 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 1506 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 1506 is configured to delete the SR policy from the first list. Further, upon receipt of the third PCEP initiate message, the second processor 1506 is configured to associate the candidate path (CP2) with the Association ID in the second list.
In accordance with yet another embodiment, an example system 1600 comprising a PCE 1602 and a PCC 1604 in communication with each other using PCEP is disclosed. In one implementation, the PCE 1602 includes the PCE 1400 disclosed with respect to
In accordance with the further embodiment, the first transceiver of the PCE 1602 is configured to perform the functionalities disclosed with respect to the first transceiver 1404 of the PCE 1400. Further, the second transceiver and the second processor are configured to perform the functionalities of the second transceiver 1504 and the second processor 1506, respectively, of the PCC 1500.
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, that scope including all equivalents of the subject matter of the claims. 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.
Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the disclosure be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the disclosure of the embodiments of the disclosure is intended to be illustrative, but not limiting, of the scope of the disclosure, which is set forth in the following claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202031055293 | Dec 2020 | IN | national |
This application is a continuation of International Application No. PCT/CN2021/139782, filed on Dec. 20, 2021, which claims priority to India Patent Application No. IN202031055293, filed Dec. 18, 2020. The disclosures of the aforementioned applications are hereby incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2021/139782 | Dec 2021 | US |
| Child | 18336058 | US |
