Patent Description:
In a network implementing source routing, a controller that has knowledge of a complete topology of the underlying network and can program an ingress node of the network with a custom path that certain traffic has to travel to reach a destination. This custom path may not necessarily be the shortest path between the ingress node and egress node. An ingress node in the network may use a separate flow classification technique ((e.g., a source and/or destination addresses or transport port numbers) to associate certain traffic flow with a custom path.

In a network implementing segment routing (SR), packets are steered through the network using segment identifiers (SIDs) that uniquely identify segments in the network. A segment may include one or more nodes, interfaces, and links between two nodes in the network. The SIDs are typically carried in the header of the packet.

Currently there are two data planes that use segment routing to provision custom paths in a network - Segment Routing (SR) Multi-Protocol Label Switching (MPLS) (SR-MPLS) and SR-Internet Protocol (IP) Version <NUM> (IPv6) (SR-IPv6). In SR-MPLS, each segment is encoded as a label, and an ordered list of segments are encoded as a stack of labels in the header of the packet. Similarly, in SR-IPv6, each segment is encoded as an IPv6 address within a segment routing header (SRH).

Document <CIT> discloses an automatic configuration of label switched path tunnels using Broader Gateway Protocol (BGP) attributes. The techniques for automatically establishing network tunnels among a set of routers are described therein. Document <CIT> discloses BGP link-state extensions for segment routing. Mechanisms by which link-state path information can be collected from networks and shared with external components are described therein.

Embodiments of the present invention are defined by a method implemented by a network element (NE) in a network by independent claim <NUM>, a network element implemented in a network is provided by independent claim <NUM>, a non-transitory medium configured to store a computer program product is provided by independent claim <NUM>, and an apparatus is provided by independent claim <NUM>. In the following, parts of the description and drawings referring to embodiments that are not covered by the claims are not presented as embodiments of the invention, but as examples useful for understanding the invention.

Source routing mechanisms, such as segment routing, have been defined for MPLS and IPv6 data planes. However, existing source routing mechanisms do not enable paths to be provisioned based on traffic engineering (TE) parameters such that the provisioned paths satisfy certain Quality of Service (QoS) parameters. In addition, existing path provisioning protocols do not include mechanisms by which to monitor the usage of various resources on the provisioned path such that the path can be re-provisioned if the path no longer satisfies the QoS parameters.

Disclosed herein are various embodiments directed to reserving resources on a Preferred Path Route (PPR) (also referred to herein as a "preferred path" or a "PPR path") between a source and a destination based on attributes defining a TE parameter or a network characteristic of the PPR. In an embodiment, a network element (NE) in a network sends an advertisement that includes PPR information describing a PPR to other NEs in the network. The PPR information includes a PPR-identifier (ID) identifying the PPR and one or more attributes related to the resource that should be reserved on the PPR. After the resources have been successfully reserved on the PPR, NEs on the PPR monitor the usage of the resources on the PPR to collect usage statistics describing used or unused resources on the PPR. The NEs on the PPR send the usage statistics to a central entity of the PPR. In this way, the embodiments disclosed herein enable a mechanism to provision PPRs that satisfy QoS parameters based on attributes specified for the PPRs and a mechanism to monitor the resources reserved on the PPRs.

<FIG> is a diagram illustrating a network <NUM> (also referred to herein as a "domain or "subnetwork") configured to implement preferred path routing according to various embodiments of the disclosure. The network <NUM> comprises a source <NUM>, a destination <NUM>, a central entity <NUM> (also referred to herein as a "controller", two areas 150A and 150B, and central entity-to-area links <NUM>-<NUM>. The source <NUM> is connected to network <NUM> via a source-to-domain link <NUM>, and the destination is connected to network <NUM> via a destination-to-domain link <NUM>.

In an embodiment, the central entity <NUM> may be a network or domain controller that maintains a topology of the network <NUM> to craft paths (both shortest paths <NUM> and PPRs <NUM>) between edge NEs <NUM>-<NUM> in the network <NUM>, as will be further described below. In an embodiment, the central entity is substantially similar to a Path Computation Element (PCE), which is further described in <NPL>. In an embodiment, the central entity <NUM> may be substantially similar to a Software Defined Network Controller (SDNC), which is further described in the <NPL>. In an embodiment, the central entity <NUM> may be substantially similar to an Application Layer Traffic Optimization (ALTO) server, which is further described in the <NPL>.

Areas 150A-B are subnetworks within the network <NUM> that may be associated with a specific geographic area or building. Each of areas 150A-B may be operated by a different operator or service provider. As shown by <FIG>, area 150A comprises elements <NUM>-<NUM> and <NUM>-<NUM> (e.g., NEs <NUM>-<NUM> interconnected by links <NUM>-<NUM>). Area 150B comprises elements <NUM>-<NUM> and <NUM>-<NUM> (e.g., NEs <NUM>-<NUM> interconnected by links <NUM>-<NUM>). As shown by <FIG>, areas 150A-B both share two NEs <NUM>-<NUM> and link <NUM>. NEs <NUM>-<NUM> and link <NUM> may be configured to operate within both areas 150A-B using a packet forwarding protocol implemented by both areas 150A-B.

In an embodiment, NEs <NUM>-<NUM> (also referred to herein as "nodes") may be a topological devices (or physical devices) such as a router, a bridge, a network switch, or a logical device configured to perform switching and routing using the preferred path routing mechanisms disclosed herein. In an embodiment, one or more of the NEs <NUM>-<NUM> may be non-topological NEs such as, for example, a function, context, service, or a virtual machine.

In an embodiment, NEs <NUM>-<NUM> may be headend nodes or edge nodes positioned at an edge of the network <NUM>. For example, NE <NUM> may be an ingress node at which packets are received (either from a source or another NE from another network/domain), and NE <NUM> may be an egress node from which traffic is transmitted (either to a destination or another NE in another network/domain). While NEs <NUM>-<NUM> are shown in <FIG> as headend nodes, it should be appreciated that NEs <NUM>-<NUM> may otherwise be an intermediate node or any other type of NE. Although only twelve NEs <NUM>-<NUM> are shown in <FIG>, it should be appreciated that the network <NUM> shown in <FIG> may include any number of NEs.

In an embodiment, the central entity <NUM> and NEs <NUM>-<NUM> are configured to implement various packet forwarding protocols, such as, but not limited to, Multi-Protocol Label Switching (MPLS), Segment Routing-MPLS (SR-MPLS), Internet Protocol (IP) Version <NUM> (IPv4), IP Version <NUM> (IPv6), Next Generation Explicit Routing (NGER), or Big Packet Protocol. In an embodiment, each area 150A and 150B may be configured to implement a different packet forwarding protocol. For example, NEs <NUM>-<NUM> in area 150A are configured to implement MPLS, while NEs <NUM>-<NUM> in area 150B are configured to implement IPv6. In such an embodiment, NEs <NUM> and <NUM>, which are shared between the two areas 150A-B, may be configured to implement both packet forwarding protocols to ensure proper data transmission between areas 150A-B.

The links <NUM>-<NUM> may be wired or wireless links or interfaces interconnecting the NEs <NUM>-<NUM> together. The central entity-to-area links <NUM>-<NUM> are also wired or wireless links or interfaces interconnecting at least one of the NEs <NUM>-<NUM> within an area 150A-B to the central entity <NUM>. As described above, the source <NUM> is connected to network <NUM> via a source-to-domain link <NUM>, and the destination is connected to network <NUM> via a destination-to-domain link <NUM>. The source-to-domain link <NUM> and the destination-to-domain link <NUM> may be wired or wireless links or interfaces interconnecting each of the source <NUM> and the destination <NUM> to an NE <NUM> and NE <NUM>, respectively, of the network <NUM>.

In operation, the central entity <NUM> is configured to determine one or more shortest paths <NUM> between two edge NEs <NUM>-<NUM> in the network <NUM> and one or more PPRs <NUM> between two edge NEs <NUM>-<NUM> in the network <NUM>. A shortest path <NUM> refers to a path between two NEs <NUM> and <NUM> (ingress NE <NUM> and egress NE <NUM>) or between a source <NUM> and destination <NUM> that is determined based on a metric, such as, for example, a cost or weight associated with each link on the path, a number of NEs on the path, a number of links on the path, etc. In an embodiment, a shortest path <NUM> may be computed for a destination using a Dijkstra's Shortest Path First (SPF) algorithm.

A PPR <NUM> (also referred to herein as a Non-Shortest Path (NSP)) refers to a custom path or any other path that is determined based on an application or server request for a path between an ingress NE <NUM> and an egress NE <NUM> or between a source <NUM> and destination <NUM>. In an embodiment, the PPR <NUM> deviates from the shortest path <NUM>. However, the PPR <NUM> may also be the same as the shortest path <NUM> in some circumstances.

In an embodiment, the central entity <NUM> is configured to determine the PPR <NUM> based on attributes specified for the PPR <NUM>. As will be further described below, an attribute specified for the PPR <NUM> may be one or more TE parameters, network characteristics, or service requirements that are associated with a resource to be reserved on the PPR <NUM>. In an embodiment, the attribute may include a bandwidth requirement, a maximum burst size, a latency requirement, a minimum jitter, a minimum error rate, a required throughput, etc. In an embodiment, reserving resources on the NEs <NUM>-<NUM> and links <NUM>-<NUM> of the PPR <NUM> according to the attributes specified for the PPR <NUM> ensures that data packets being transmitted along the PPR <NUM> satisfy a certain QoS parameter set by the source <NUM> of the PPR <NUM> or an operator of the network <NUM>.

In an embodiment, a source <NUM>, or an ingress NE <NUM>, transmits a request to the central entity <NUM> to compute a PPR <NUM> between the source <NUM> and the destination <NUM> (or between the ingress NE <NUM> and the egress NE <NUM>) according to a particular attribute. In another embodiment, the attributes for a particular PPR <NUM> may be preconfigured at the central entity <NUM> by an operator or service provider of the network <NUM>. In another embodiment, the central entity <NUM> is configured to determine the PPR <NUM> according to the attribute requested.

The PPRs <NUM> and the shortest paths <NUM> may each comprise a sequential ordering of one or more elements <NUM>-<NUM> and <NUM>-<NUM> (e.g., NEs <NUM>-<NUM> and links <NUM>-<NUM>) in the network <NUM>. As shown in <FIG>, the shortest path <NUM> between ingress NE <NUM> and egress NE <NUM> includes the following elements: NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, and NE <NUM>. As described above, the shortest path <NUM> between ingress NE <NUM> and egress NE <NUM> is based on metrics of each of the elements <NUM>-<NUM> and <NUM>-<NUM> in the network <NUM>.

In contrast, the PPR <NUM> between ingress NE <NUM> and egress NE <NUM> includes the following elements: NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, and NE <NUM>. In an embodiment, the central entity <NUM> determines the elements on the PPR <NUM> based on an attribute, such as, bandwidth, latency, or burst size, of each of one or more of the elements (NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, and NE <NUM>) on PPR <NUM>.

After the central entity <NUM> determines the PPR <NUM> based on the attribute, the central entity <NUM> transmits PPR information describing the PPR <NUM> to a headend or ingress NE <NUM>-<NUM> in each area 150A-B of network <NUM>. For example, the central entity <NUM> transmits PPR information describing the PPR <NUM> implemented in area 150A to NE <NUM> via central entity-to-area link <NUM>. Similarly, the central entity <NUM> transmits PPR information describing the PPR <NUM> implemented in area 150B to NE <NUM> via link <NUM>.

In an embodiment, the PPR information includes information that describes the PPR <NUM>. The PPR information may include, for example, a PPR-ID identifying the PPR <NUM>. In an embodiment, the PPR-ID includes a single label, address, or ID identifying the PPR <NUM>. For example, when the network <NUM> implements SR-MPLS, the PPR-ID may be an MPLS label or an SID identifying a PPR. When the network <NUM> implements IPv6, the PPR-ID may be an IPv6 SID identifying a PPR. When the network <NUM> implements IPv4, the PPR-ID may be an IPv4 address or prefix identifying a PPR. Similarly, when the network <NUM> implements IPv6, the PPR-ID may be an IPv6 address or prefix identifying a PPR.

The PPR information also includes multiple PPR-path description elements (PDEs) describing one or more elements (NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, and NE <NUM>) or segments including one or more of the elements on the PPR <NUM>. In an embodiment, each of the PPR-PDEs includes a label, address, or identifier of one or more of the elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> or segments including one or more of the elements on the PPR <NUM>. In an embodiment, the PPR-PDEs include a sequential ordering of MPLS labels, IPV6 addresses, or IPv4 addresses that specify the actual path (e.g., one or more of the elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM>) toward a destination address of the egress NE <NUM> or the destination <NUM> (also referred to herein as a "prefix"). In an embodiment, each of the PPR-PDEs may also define whether the element being described is a topological NE or a non-topological NE.

In various embodiments, two types of PPRs <NUM> may be described by the PPR-PDEs, a strict PPR <NUM> and a loose PPR <NUM>. In a strict PPR <NUM>, every single NE (NE <NUM>, NE <NUM>, NE <NUM>, NE <NUM>, NE <NUM>, NE <NUM>, and NE <NUM>) along the PPR <NUM> is specified or described in its own PPR-PDE. In a loose PPR <NUM>, certain elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> (also referred to herein as "hops") along a PPR <NUM> may be skipped such that only a subset of the elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> along a PPR <NUM> is specified or described in its own PPR-PDE. When loose PPRs <NUM> are described by the PPR-PDEs, the NEs along the path use shortest path routing in between elements that are not explicitly specified in a PPR-PDE (i.e., to reach the next topological PDE of the loose PPR <NUM>).

The PPR information may include several other descriptive elements, which are further described in Patent Cooperation Treaty (PCT) <CIT>, et. , and filed on January <NUM>, <NUM> (hereinafter referred to as the "PPR Patent"). For example, the PPR information may include a PPR type, defining an encoding scheme used to encode the PPR-ID. For example, when the PPR-ID is an IPv4 address, then the PPR type is a value indicating that the PPR-ID is an IPv4 address. Similarly, when the PPR-ID is an IPv6 address or an MPLS label, then the PPR type is a value indicating that the PPR-ID is an IPv6 address or an MPLS label. The PPR information may also include various flags. For example, one bit may indicate whether all the NEs in the network <NUM> downloads the PPR information or only a subset of the NEs identified in the PPR-PDEs downloads the PPR information.

In an embodiment, the PPR information may also include one or more attributes associated with a resource to be reserved on the PPR <NUM>. As described above, the attribute refers to a TE parameter network characteristic that should be satisfied when reserving a resource on the PPR <NUM>. Examples of attributes specified for a PPR <NUM> may include bandwidth, burst size, latency, and lifetime, which will be further described below with reference to <FIG> and <FIG>.

After receiving the PPR information, NEs <NUM> and <NUM> first determine whether the NEs <NUM> and <NUM> are identified in a PPR-PDE of the PPR information. When a PPR-PDE does not identify the NE <NUM> or <NUM>, NEs <NUM> and <NUM> ignore the PPR information. In contrast, when a PPR-PDE identifies the NE <NUM> or <NUM>, the NE <NUM> or <NUM> updates a local forwarding database to include an entry including the PPR information for a destination address corresponding to the egress NE <NUM> or the destination <NUM>.

In an embodiment, the local forwarding database is updated by adding another entry for a particular destination ID or address of the egress NE <NUM> or the destination <NUM>. The new entry includes at least one of the PPR-ID, each of the PPR-PDEs corresponding the PPR-ID, an ID or address of the next element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> on the PPR <NUM> to which to forward a data packet, and the one or more attributes specified for the PPR <NUM>. In another embodiment, NEs <NUM> and <NUM> are configured to update the local forwarding database to include the PPR information relative to a destination address of the egress NE <NUM> or the destination <NUM> regardless of whether the NE <NUM> or <NUM> is identified in a PPR-PDE of the PPR information.

After receiving the PPR information and updating a local forwarding database, the NEs <NUM> and <NUM> send (or flood) an advertisement including the PPR information to all of the other NEs <NUM>-<NUM> in the respective area 150A-B of network <NUM> using the underlying Interior Gateway Protocol (IGP) of the respective area 150A-B. The advertisement including the PPR information may be encoded and flooded through the respective area 150A-B using an IGP, such as, for example, Open Shortest Path First (OSPF) Version <NUM> (OSPFv2), OSPF Version <NUM> (OSPFv3), Intermediate System - Intermediate System (IS-IS), or direct SDN. For example, after receiving the PPR information, the NE <NUM> transmits (or floods) the PPR information to NEs <NUM>-<NUM> and <NUM>-<NUM> in area 150A according to the IGP implemented by area 150A. Similarly, after receiving the PPR information, NE <NUM> transmits (or floods) the PPR information to NEs <NUM>-<NUM> and <NUM>-<NUM> in area 150B according to the IGP implemented by area 150B.

In an embodiment, each of the receiving NEs <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> determines whether the receiving NE <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> is identified in a PPR-PDE of the PPR information. In an embodiment, when a PPR-PDE identifies the receiving NE <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM>, the receiving NE <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> updates a local forwarding database to include an entry including the PPR information for a destination address corresponding to the egress NE <NUM> or the destination <NUM>. In this embodiment, when a PPR-PDE does not identify the receiving NE <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM>, the receiving NE <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> ignores the PPR information. In another embodiment, each of the receiving NEs <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> updates a local forwarding database to include an entry including the PPR information regardless of whether the NE is identified in a PPR-PDE.

The embodiments disclosed herein are directed to advertising and programming one or more attributes defining network characteristics related to a resource to be reserved on the PPR <NUM> along with the basic PPR information (e.g., PPR-ID and PPR-PDEs). As the NEs <NUM>-<NUM> receive the PPR information including the PPR-ID, PPR-PDEs, and the attributes, the NEs <NUM>-<NUM> update the local forwarding databases and thereby become programmed to construct the PPR <NUM> based on the attributes defined by the PPR information. In this way, the PPR <NUM> is constructed to ensure that the PPR <NUM> satisfies QoS parameters defined using the attributes included in the PPR information.

In an embodiment, preferred path routing is extended to indicate the resources (e.g., attributes) to be reserved along the PPR. The resources indicated are not only for providing a committed bandwidth or deterministic latency, but also for assuring an overall service level guarantee on the network <NUM>. In an embodiment, reservations are included in the PPR information in terms of required resources (bandwidth), traffic characteristics (burst size), and service level parameters (expected maximum latency at each hop) based on the capabilities of each element on the PPR <NUM>.

<FIG> is a diagram illustrating the network <NUM> configured to implement preferred path routing according to various embodiments of the disclosure. As shown by <FIG>, the NEs <NUM>-<NUM> within the areas 150A-B of the network <NUM> exchange data with another to reserve resources along a PPR <NUM> and monitor the resources along the PPR <NUM>. The data that can be exchanged includes a node resource capability <NUM>, PPR information <NUM>, a node status <NUM>, and usage statistics <NUM>. It should be appreciated that other data relevant to the PPR <NUM> may be exchanged among NEs <NUM>-<NUM> within the areas 150A-B of the network <NUM> for the purpose of reserving and monitoring resources along the PPR <NUM>.

First, each NE <NUM>-<NUM> within the network <NUM> advertises a node resource capability <NUM> to all of the other NEs <NUM>-<NUM> within a respective area 150A-B to indicate that the NE <NUM>-<NUM> is located using the underlying IGP. For example, NE <NUM> sends a node resource capability <NUM> to NEs <NUM>-<NUM> in area 150A, and NE <NUM> sends a node resource capability <NUM> to NEs <NUM>-<NUM> in area 150B. In an embodiment, the node resource capability <NUM> is flooded to other NEs <NUM>-<NUM> in the network <NUM> before the PPR information <NUM> is flooded to other NEs <NUM>-<NUM> in the network <NUM>.

In an embodiment, the node resource capability <NUM> is sent to the central entity <NUM> via central entity-to-area links <NUM>-<NUM> periodically or through any other offline mechanism. For example, supposing that NE <NUM> is a Border Gateway Protocol (BGP) Link State (BGP-LS) speaker, NE <NUM> may transmit the node resource capability <NUM> to the central entity <NUM>. In an embodiment, the node resource capability <NUM> is encoded according to BGP-LS Prefix Network Layer Reachability Information (NLRI) when the node resource capability <NUM> is transmitted to the central entity <NUM>.

A node resource capability <NUM> is a message sent by each NE <NUM>-<NUM> within a network <NUM> that indicates various capabilities of the NE <NUM>-<NUM> sending the node resource capability <NUM>. In an embodiment, the node resource capability <NUM> is provisioned by a central entity <NUM> and flooded to other NEs <NUM>-<NUM> in the network <NUM> before the PPR information <NUM> is flooded to other NEs <NUM>-<NUM> in the network <NUM>.

The node resource capability <NUM> indicates various different capabilities of, or features supported by, the NE <NUM>-<NUM> sending the node resource capability <NUM>. In an embodiment, the node resource capability <NUM> indicates whether the NE <NUM>-<NUM> sending the node resource capability <NUM> is capable of implementing preferred path routing. In an embodiment, the node resource capability <NUM> indicates one or more attributes that are supported by sending the node resource capability <NUM>. For example, the node resource capability <NUM> indicates whether the NE <NUM>-<NUM> sending the node resource capability <NUM> is capable of reserving a resource on the PPR <NUM> according to one or more different attributes. In an embodiment, the node resource capability <NUM> indicates whether the NE <NUM>-<NUM> sending the node resource capability <NUM> is capable of monitoring usage statistics <NUM> related to the resources reserved for the PPR <NUM>.

In an embodiment, the node resource capability <NUM> includes one or more flags indicating whether the NE <NUM>-<NUM> sending the node resource capability <NUM> is capable of implementing preferred path routing. The node resource capability <NUM> also includes one or more flags indicating each of the attributes that the NE <NUM>-<NUM> is capable of supporting to reserve a resource on a PPR <NUM>. The node resource capability <NUM> also includes one or more flags indicating each of the usage statistics that NE <NUM>-<NUM> is capable of monitoring.

According to the claimed invention, the NE transmits node resource capabilities including one or more flags indicating usage statistics, which the NE is capable of monitoring for the resource reserved in the network to a central entity of the PPR.

In an embodiment, the node resource capability <NUM> is a new message defined by the preferred path routing protocol. In another embodiment, the node resource capability <NUM> is a sub Type-Length-Value (TLV) within a body of an IS-IS capable TLV, as further described in IETF RFC <NUM>, entitled "IS-IS Extension for Advertising Router Information," by L. Ginsberg, dated October <NUM>. Additional detail regarding the node resource capability <NUM> is further described below with reference to <FIG>.

Second, one or more NEs <NUM>-<NUM> within the network <NUM> may transmit usage statistics <NUM> to the central entity <NUM> periodically or through any other offline mechanism such as gRPC, KAFKA or through streaming telemetry.

After receiving the PPR information <NUM> from the central entity <NUM> or locally provisioned by the operator at one or more NEs <NUM>-<NUM> advertises the PPR information <NUM> describing PPR <NUM> to all of the other NEs <NUM>-<NUM> within a respective area 150A-B that the NE <NUM>-<NUM> is located using the underlying IGP. In an embodiment, the PPR information <NUM> may be included with an advertisement or a PPR-TLV, as described in the PPR Patent. For example, assuming that NE <NUM> receives the PPR information <NUM> describing the PPR <NUM> from the central entity <NUM> (or otherwise an external entity or operator of the network <NUM>), the NE <NUM> transmits the PPR information <NUM> to the other NEs <NUM>-<NUM> and <NUM>-<NUM> in area 150A of the network <NUM>. Similarly, assuming that NE <NUM> receives the PPR information <NUM> describing the PPR <NUM> from the central entity <NUM> (or otherwise an external entity or operator of the network <NUM>), the NE <NUM> transmits the PPR information <NUM> to the other NEs <NUM>-<NUM> and <NUM>-<NUM> in area 150B of the network <NUM>.

As shown in <FIG> and described above, the PPR information <NUM> may include information describing the PPR <NUM>, such as, for example, the PPR-ID <NUM> identifying the PPR <NUM>. The PPR information <NUM> may also include one or more PPR-PDEs <NUM> describing one or more elements on the PPR <NUM>. Each PPR-PDE <NUM> may include an address, label, or ID of an element on the PPR <NUM>. The PPR information <NUM> may also include one or more attributes <NUM> associated with a resource to be reserved on the PPR <NUM>. As described above, the PPR-ID <NUM> is a label, address, or ID that uniquely identifies the PPR <NUM>, and the attributes <NUM> refer to network characteristics or TE parameters by which a certain resource on the PPR <NUM> is reserved. In an embodiment, the attributes <NUM> are enforced by one or more elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> to ensure that the PPR <NUM> satisfies certain QoS parameters.

In an embodiment, the attributes <NUM> specify a bandwidth, a burst size, a per-hop queueing latency, or a lifetime of the PPR <NUM>. For example, the attributes <NUM> for a PPR <NUM> may specify a minimum bandwidth or a maximum bandwidth required to transmit a data packet along a link <NUM>-<NUM> of the PPR <NUM>. The attributes <NUM> for a PPR <NUM> may specify a required or maximum burst size of a burst transmitted along a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>. The attributes <NUM> for a PPR <NUM> may specify a per-hop queuing latency, which indicates a bounded latency for each NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> or hop on the PPR <NUM>. The attributes <NUM> may also specify a lifetime of the reservations made for the PPR <NUM> such that the reservations are torn down upon expiration of the lifetime, unless the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> receives a state refresh of the PPR <NUM>, which will be further described below. Additional details and examples of the attributes <NUM> are further described below with regard to <FIG> and <FIG>. Although only these four examples of attributes <NUM> are described herein, it should be appreciated that attributes <NUM> include any other TE parameter or network characteristic that may be used to provide a certain QoS to clients transmitting and receiving data packets along the PPR <NUM>.

In an embodiment, upon receiving the PPR information <NUM> from other NEs <NUM>-<NUM> in the network <NUM>, the receiving NEs <NUM>-<NUM> are configured to program the PPR <NUM> according to the PPR information <NUM>. Programming the PPR <NUM> according to the PPR information <NUM> includes updating a local forwarding database stored at the NE <NUM>-<NUM> to include the PPR information <NUM> in association with a destination address corresponding to the egress NE <NUM> of the PPR <NUM> or the destination <NUM>. In an embodiment, the NE <NUM>-<NUM> updates the local forwarding database to include the attributes <NUM> along with the PPR-ID <NUM> and the PPR-PDEs specified by the PPR information <NUM>. As described above, in one embodiment, the local forwarding database is updated only when the PPR-PDEs include the NE <NUM>-<NUM> that received the PPR information <NUM>, and in another embodiment, the local forwarding database is updated regardless of whether the PPR-PDEs include the NE <NUM>-<NUM> received the PPR information <NUM>.

After updating the local forwarding database based on the received PPR information <NUM>, each of the NEs <NUM>-<NUM> transmits (or floods) a node status <NUM> to the other NEs <NUM>-<NUM> in a respective area 150A-B of the network <NUM> using the underlying IGP. For example, after updating the local forwarding database to include the PPR information <NUM>, the NE <NUM> transmits a node status <NUM> to NEs <NUM>-<NUM> and <NUM>-<NUM> within area 150A. Similarly, after updating the local forwarding database to include the PPR information <NUM>, the NE <NUM> transmits a node status <NUM> to NEs <NUM>-<NUM> and <NUM>-<NUM> within area 150B.

A node status <NUM> indicates whether a resource for the PPR <NUM> has been successfully reserved according to the attribute <NUM> included in the PPR information <NUM>. In an embodiment, the node status <NUM> indicates a successful reservation of the resource for the PPR <NUM> when the local forwarding database of the NE <NUM>-<NUM> sending the node status <NUM> has been successfully updated to include the PPR information <NUM>, including the attribute <NUM>. In an embodiment, the node status <NUM> indicates a failure to reserve one or more resources for the PPR <NUM> when the local forwarding database of the NE <NUM>-<NUM> sending the node status <NUM> has not been successfully updated to include the PPR information <NUM>, including the attribute <NUM>. Additional details regarding the node status <NUM> are further described below with regard to <FIG>.

After updating the local forwarding database and sending the node status <NUM>, data packets may be forwarded along the PPR <NUM> in the data plane. As further described in the PPR Patent, only data packets that include the PPR-ID <NUM> are forwarded along the PPR <NUM>. For example, assuming NE <NUM> receives a data packet with a PPR-ID <NUM> in a header of the data packet, the NE <NUM> performs a lookup at the local forwarding database using the PPR-ID <NUM> to determine a next hop (e.g., next element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> or next segment). In an embodiment, the forwarding database includes entries corresponding to destination addresses and PPR-IDs <NUM> indicating the next hop or element toward which to forward a data packet. The lookup may be performed at the local database by searching the forwarding database for the entry corresponding to the destination address and PPR-ID <NUM> included in the data packet The data packet is then forwarded toward the next hop based on the PPR-PDEs stored in association with the PPR-ID <NUM> in the entry of the forwarding database.

In an embodiment, the NE <NUM> is also configured to perform the lookup at the local forwarding database to determine an attribute <NUM> associated with a resource reserved for this PPR <NUM> and then determines whether the path to the next hop on the PPR <NUM> satisfies the attribute <NUM>. When the determined next hop on the PPR <NUM> satisfies the attribute <NUM>, the NE <NUM> forwards to the data packet to the next hop on the PPR <NUM> (e.g., along link <NUM> to NE <NUM>). In this manner, each of the NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> to the egress NE <NUM> determines whether a next hop on the PPR <NUM> satisfies the attribute <NUM> and forwards the data packet to the next hop only when the next hop satisfies the attribute <NUM>.

As data packets continue to be forwarded on the PPR <NUM> in the data plane, each of the NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> monitor and collect usage statistics <NUM> of network resources along the PPR <NUM>. In an embodiment, usage statistics <NUM> refer to statistics regarding the usage of various resources along the PPR <NUM>. In an embodiment, each of the NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may be pre-configured by, for example, the operator of the network <NUM> or the central entity <NUM> to monitor usage statistics <NUM> of network resources along the PPR <NUM> or other paths along which the NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> transmit data.

After collecting the usage statistics <NUM>, one or more of the NEs <NUM>-<NUM> may transmit the usage statistics <NUM> to the central entity <NUM> periodically or through any other offline mechanism such as gRPC, KAFKA or other streaming telemetry tools.

For example, assuming NE <NUM> collects usage statistics <NUM>, such as the utilized bandwidth at link <NUM> along the PPR <NUM>, the NE <NUM> may transmit this usage statistic <NUM> to the other NEs <NUM>-<NUM> and <NUM>-<NUM> in the area 150A using the underlying IGP. In an embodiment, the NE <NUM>-<NUM> within the network <NUM> that is configured to perform northbound communication with the central entity <NUM> to transmit control data to the central entity <NUM> transmits the usage statistics <NUM> to the central entity <NUM>. For example, assume that the NE <NUM> is configured as the Border Gateway Protocol (BGP) Link Sate (BGP-LS) speaker enabled with BGP to perform northbound communication with the central entity <NUM>. In this case, NE <NUM> transmits the usage statistics <NUM> to the central entity <NUM> using BGP-LS after having received the usage statistics <NUM> from NE <NUM>. In another embodiment, the central entity <NUM> may request and receive usage statistics <NUM> directly from any of the NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the path using, for example, protocols such as g-Remote Procedure Calls (gRPC) or KAFKA.

In an embodiment, usage statistics <NUM> include data regarding the amount of used or unused resources on the PPR <NUM>. The usage statistics <NUM> may include a per-PPR queuing delay occurring at an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> on a PPR <NUM> and a PPR bandwidth describing a utilized bandwidth on a link <NUM>-<NUM> and <NUM>-<NUM> attached to an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> on a PPR <NUM>. The PPR bandwidth may also describe bandwidth violations occurring on a link <NUM>-<NUM> and <NUM>-135attached to an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> on a PPR <NUM>. Additional details and examples of the usage statistics <NUM> are further described below with regard to <FIG>. Although only these two examples of usage statistics <NUM> are described herein, it should be appreciated that usage statistics <NUM> includes any other measurement of utilized or unutilized network resources on a PPR <NUM>.

<FIG> is a diagram of an embodiment of an NE <NUM> in a network such as the network <NUM>. NE <NUM> may be implemented as the central entity <NUM> or the NEs <NUM>-<NUM>. The NE <NUM> may be configured to implement and/or support the routing mechanisms described herein. The NE <NUM> may be implemented in a single node or the functionality of NE <NUM> may be implemented in a plurality of nodes. One skilled in the art will recognize that the term NE encompasses a broad range of devices of which NE <NUM> is merely an example. While NE <NUM> is described as a physical device, such as a router or gateway, the NE <NUM> may also be a virtual device implemented as a router or gateway running on a server or a generic routing hardware (whitebox).

The NE <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 NE embodiment or class of NE embodiments. At least some of the features and/or methods described in the disclosure may be implemented in a network apparatus or module such as a NE <NUM>. For instance, the features and/or methods in the disclosure may be implemented using hardware, firmware, and/or software installed to run on hardware. As shown in <FIG>, the NE <NUM> comprises one or more ingress ports <NUM> and a receiver unit (Rx) <NUM> for receiving data, at least one processor, logic unit, or central processing unit (CPU) <NUM> to process the data, transmitter unit (Tx) <NUM> and one or more egress ports <NUM> for transmitting the data, and a memory <NUM> for storing the data.

The processor <NUM> may comprise one or more multi-core processors and be coupled to a memory <NUM>, which may function as data stores, buffers, etc. The processor <NUM> may be implemented as a general processor or may be part of one or more application specific integrated circuits (ASICs) and/or digital signal processors (DSPs). The processor <NUM> may comprise a network configuration module <NUM>, which may perform processing functions of the central entity <NUM> or the NEs <NUM>-<NUM>. The network configuration module <NUM> may also be configured to perform the steps of method <NUM>, and/or any other method discussed herein. As such, the inclusion of the network configuration module <NUM> and associated methods and systems provide improvements to the functionality of the NE <NUM>. Further, the network configuration module <NUM> effects a transformation of a particular article (e.g., the network) to a different state. In an alternative embodiment, network configuration module <NUM> may be implemented as instructions stored in the memory <NUM>, which may be executed by the processor <NUM>.

The memory <NUM> may comprise a cache for temporarily storing content, e.g., a random-access memory (RAM). Additionally, the memory <NUM> may comprise a long-term storage for storing content relatively longer, e.g., a read-only memory (ROM). For instance, the cache and the long-term storage may include dynamic RAMs (DRAMs), solid-state drives (SSDs), hard disks, or combinations thereof. The memory <NUM> may be configured to store the PPR information <NUM>, which includes PPR-IDs <NUM>, attributes <NUM>, and the PPR-PDEs <NUM>. In addition, the memory <NUM> is configured to store the node resource capability <NUM>, usage statistics <NUM>, a forwarding database <NUM>, and a link state database <NUM>. In an embodiment, the forwarding database <NUM> stores entries describing forwarding rules for how a particular NE <NUM> (e.g., NE <NUM>-<NUM> of <FIG>) should forward a data packet that includes a PPR-ID <NUM> and/or a destination address.

It is understood that by programming and/or loading executable instructions onto the NE <NUM>, at least one of the processor <NUM> and/or memory <NUM> are changed, transforming the NE <NUM> in part into a particular machine or apparatus, e.g., a multi-core forwarding architecture, having the novel 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 may be 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 may be preferred to be implemented in hardware, for example in an ASIC, because for large production runs the hardware implementation may be less expensive than the software implementation. Often a design may be 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 in a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus. In some embodiments, the NE <NUM> may be configured to implement OSPFv2, OSPFv3, IS-IS, or direct SDN controller based on network implementations.

<FIG> are diagrams illustrating examples of a node resource capability <NUM> sent by an NE <NUM>-<NUM> in the network <NUM>, and fields within the node resource capability <NUM>, according to various embodiments of the disclosure. In particular, <FIG> is a diagram illustrating an example of a node resource capability <NUM> sent by an NE <NUM>-<NUM> to every other NE <NUM>-<NUM> in the area 150A-B or the network <NUM> and the central entity <NUM> according to various embodiments of the disclosure. As described above, the node resource capability <NUM> indicates various different capabilities of the NE <NUM>-<NUM> sending the node resource capability <NUM>.

As shown in <FIG>, the node resource capability <NUM> includes a node ID <NUM> identifying the NE <NUM>-<NUM> sending the node resource capability <NUM>. The node ID <NUM> may be a label, address, or ID that uniquely identifies the NE <NUM>-<NUM> sending the node resource capability <NUM>.

The node resource capability <NUM> also includes resource reservation capabilities <NUM>. The resource reservation capabilities <NUM> may include one or more flags indicating whether the NE <NUM>-<NUM> sending the node resource capability <NUM> is capable of reserving a resource on the PPR <NUM> according to an attribute <NUM>. In an embodiment, the resource reservation capabilities <NUM> includes a flag indicating whether reserving a minimum or maximum bandwidth on a link <NUM>-<NUM> attached the NE <NUM>-<NUM> sending the node resource capability <NUM> is supported by the NE <NUM>-<NUM>. In an embodiment, the resource reservation capabilities <NUM> includes a flag indicating whether setting a burst size or maximum burst size permitted to be transmitted on a link <NUM>-<NUM> attached the NE <NUM>-<NUM> sending the node resource capability <NUM> is supported by the NE <NUM>-<NUM>. In an embodiment, the resource reservation capabilities <NUM> includes a flag indicating whether enforcing a per hop maximum queuing latency at the NE <NUM>-<NUM> sending the node resource capability <NUM> is supported by the NE <NUM>-<NUM>. In an embodiment, the resource reservation capabilities <NUM> includes a flag which indicates whether setting and enforcing a lifetime or expiration timer for the PPR <NUM> is supported by the NE <NUM>-<NUM>.

<FIG> shows an example a node resource capability <NUM> defined within a body of the IS-IS Router Capability TLV, as defined by RFC <NUM>, according to various embodiments of the disclosure. The node resource capability <NUM> also defines all the TE parameters that are supported by the NE <NUM>-<NUM> sending the node resource capability <NUM>.

As shown by <FIG>, the node resource capability <NUM> includes a type field <NUM>, a length field <NUM>, and reservation capability (RC) flags field <NUM>. The type field <NUM> may include a value assigned by the Internet Assigned Numbers Authority (IANA) from the IS-IS Router Capability TLV Registry. The value carried in the type field <NUM> indicates that the node resource capability <NUM> includes RC flags <NUM> related to resource reservation capabilities <NUM> on a PPR <NUM>. The length field <NUM> includes a value indicating a total length of the node resource capability <NUM> in bytes. The RC flags field <NUM> is a <NUM> octet field including multiple flags, as represented in the reservation capability sub-TLV shown in <FIG>.

<FIG> shows an example of a reservation capability sub-TLV <NUM> that is included in the RC flags field <NUM> according to various embodiments of the disclosure. The RC flags field <NUM> may include four flags or bits: a B flag <NUM>, a S flag <NUM>, a L flag <NUM>, a T flag <NUM>, reserved bits <NUM>, and an E flag <NUM>.

The B flag <NUM>, also referred to as Bit-<NUM> or the B Bit, is set to indicate that minimum or maximum bandwidth reservation is supported by the NE <NUM>-<NUM> sending the node resource capability <NUM>. The S flag <NUM>, also referred to as Bit-<NUM> or the S Bit, is set to indicate that burst size handling is supported by the NE <NUM>-<NUM> sending the node resource capability <NUM>. The L flag <NUM>, also referred to as Bit-<NUM> or the L Bit, is set to indicate that per-hop maximum queuing is supported by the NE <NUM>-<NUM> sending the node resource capability <NUM>. The T flag <NUM>, also referred to as Bit-<NUM> or the T Bit, is set to indicate that a lifetime, or expiration timer for the PPR <NUM> is supported by the NE <NUM>-<NUM> sending the node resource capability <NUM>. The reserved bits <NUM> are empty and reserved for future use. The E flag <NUM>, also referred to as Bit-<NUM> or the E Bit, is set to indicate that one more <NUM>-bit status field follows the E flag <NUM>.

<FIG> are diagrams illustrating an example of an advertisement <NUM> sent by an NE <NUM>-<NUM> in the network <NUM>, and attributes <NUM> included in the advertisement <NUM>, according to various embodiments of the disclosure. In particular, <FIG> is a diagram illustrating an example of an advertisement <NUM> including PPR information <NUM> according to various embodiments of the disclosure. As described above, the PPR information <NUM> describing the PPR <NUM> is received by a headend NE <NUM>-<NUM> by either the central entity <NUM> or an external entity, such as an operator of network <NUM>. After receiving the PPR information <NUM>, the headend NE <NUM>-<NUM> floods the advertisement <NUM> including the PPR information <NUM> through the entire respective area 150A- using an underlying IGP of the respective area 150A-B. Flooding the advertisement <NUM> throughout the respective area 150A-B refers to transmitting the advertisement <NUM> to every other NE <NUM>-<NUM> in the respective area 150A-B. The NE <NUM>-<NUM> may also flood the advertisement <NUM> through the entire domain (e.g., network <NUM>) at which the headend NE <NUM>-<NUM> is located using an underlying IGP of the network <NUM>. Flooding the advertisement <NUM> throughout the network <NUM> refers to transmitting the advertisement <NUM> to every other NE <NUM>-<NUM> in the network <NUM>.

As shown in <FIG>, the PPR information <NUM> includes the PPR-ID <NUM>, a PPR type <NUM>, one or more PPR-PDEs 245A-N, and one or more attributes 240A-N. As described above, the PPR-ID <NUM> is a label, address, or identifier that uniquely identifies the PPR <NUM>. The PPR-ID <NUM> may be encoded in many different ways, such as, for example, as an IPv4 address, IPv6 address, or MPLS label.

The PPR type <NUM> defines the kind or type of the labels, addresses, or IDs of the PPR-ID <NUM> and/or the elements <NUM>-<NUM> and <NUM>-<NUM> (NEs <NUM>-<NUM> and links <NUM>-<NUM>) on the PPR <NUM>, which are encoded in the PPR-PDEs 245A-N. As described above, each of the PPR-PDEs 245A-N includes a label, address, or ID identifying an element <NUM>-<NUM> and <NUM>-<NUM> on the PPR <NUM>. For example, each of the elements <NUM>-<NUM> and <NUM>-<NUM> on the PPR <NUM> may be encoded as an MPLS label, an IPv4 address, an IPv6 address, etc. The PPR type <NUM> defines an encoding scheme used by the PPR-ID <NUM> and/or each of the PPR-PDEs 425A-N.

As described above, the attributes 240A-N describe one or more network characteristics or TE parameters that should be applied to at least one resource on the PPR <NUM>. Various examples of the attributes 240A-N are described below with reference to <FIG>. While <FIG> only shows the PPR information <NUM> including the PPR-ID <NUM>, the PPR type <NUM>, one or more PPR-PDEs 245A-N, and one or more attributes 240A-N, the PPR information <NUM> may include other information as described in the PPR Patent.

<FIG> is a diagram illustrating examples of the attributes 240A-N carried in the PPR information <NUM> describing a PPR <NUM> according to various embodiments of the disclosure. As shown in <FIG>, the attributes 240A-N include a bandwidth sub-TLV <NUM>, a burst size sub-TLV <NUM>, a per-hop queuing sub-TLV <NUM>, and a lifetime sub-TLV <NUM>. While only these four attributes 240A-N are shown and described with reference to <FIG>, it should be appreciated that attributes 240A-N may include any other attribute defining a TE parameter or a network characteristic for a PPR <NUM>.

The bandwidth sub-TLV <NUM> may be encoded to carry information regarding bandwidth requirement <NUM>, such as a minimum bandwidth or a maximum bandwidth required to transmit a data packet along a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>. For example, the bandwidth sub-TLV <NUM> may include a bandwidth requirement <NUM> defining a minimum bandwidth required on a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM> to permit transmitting a data packet including a PPR-ID <NUM> corresponding to the PPR <NUM> along the link <NUM>-<NUM> and <NUM>-<NUM>. Similarly, the bandwidth sub-TLV <NUM> may include a bandwidth requirement <NUM> defining a maximum bandwidth allowed on a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM> to permit transmitting a data packet including a PPR-ID <NUM> corresponding to the PPR <NUM> along the link <NUM>-<NUM> and <NUM>-<NUM>. An example of the bandwidth sub-TLV <NUM> is shown and described below with reference to <FIG>.

The burst size sub-TLV <NUM> may be encoded to carry a burst size <NUM>, such as a maximum burst size of a burst transmitted along a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>. For example, the burst size sub-TLV <NUM> may include burst size <NUM> defining a maximum burst size of a burst of data packets including the PPR-ID <NUM> permitted to be transmitted on a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>. Similarly, the burst size sub-TLV <NUM> may include a burst size <NUM> defining minimum burst size of a burst of data packets including the PPR-ID <NUM> permitted to be transmitted on a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>. An example of the burst size sub-TLV <NUM> is shown and described below with reference to <FIG>.

The per-hop queuing size sub-TLV <NUM> may be encoded to carry a bounded latency <NUM> for each element (e.g., NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, NE <NUM>, link <NUM>, and NE <NUM>) or hop on the PPR <NUM>. For example, the per-hop queuing size sub-TLV <NUM> may include a maximum bounded latency <NUM> permitted on each NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> on the PPR <NUM> such that data packets including the PPR-ID <NUM> for the PPR <NUM> may only be transmitted to NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> with a bounded latency less than the maximum bounded latency <NUM>. An example of the per-hop queuing size sub-TLV <NUM> is shown and described below with reference to <FIG>.

The lifetime sub-TLV <NUM> may be encoded to carry a lifetime <NUM> of the reservations made for the PPR <NUM> such that the reservations are teared down upon expiration of the lifetime <NUM>. In an embodiment, tearing down the reservations refers to removing the PPR information <NUM> from the forwarding database <NUM> and/or removing the reservation of the resource along an element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

The lifetime <NUM> may be indicated in the time unit of seconds. For example, the lifetime sub-TLV <NUM> may include a lifetime <NUM>, or a maximum amount of time, that a resource is reserved for a PPR <NUM>. For example, when an NE <NUM>-<NUM> receives an advertisement <NUM> with the PPR information <NUM> including a lifetime <NUM> for the PPR <NUM>, the forwarding database <NUM> is updated to indicate the lifetime <NUM>, and a soft timer is initiated and expected to expire at the time period indicated by the lifetime <NUM>.

The lifetime <NUM> may be extended when a state refresh is received by the NE <NUM>-<NUM> from which the original PPR information <NUM> was received. In an embodiment, a state refresh is another advertisement <NUM> containing the same PPR information <NUM> for the PPR information <NUM>. In an embodiment, when a state refresh is received from an originating headend NE <NUM>-<NUM> before the expiration of the soft timer, the lifetime <NUM> is reset and initiated again. If a state refresh is not received before the expiration of the soft timer, then the resources reserved for the PPR <NUM> are teared down and the forwarding database <NUM> is updated to reflect the tearing down of the PPR <NUM>. An example of the lifetime sub-TLV <NUM> is shown and described below with reference to <FIG>.

<FIG> show examples of the attributes 240A-N described in <FIG> according to various embodiments of the disclosure. <FIG> shows an example of the bandwidth sub-TLV <NUM>, <FIG> shows an example of a burst size sub-TLV <NUM>, <FIG> shows an example of a per-hop queuing sub-TLV <NUM>, and <FIG> shows an example of a lifetime sub-TLV <NUM>. In an embodiment, the sub-TLVs for the various attributes 240A-N described in <FIG> may be included in the IS-IS PPR Attribute Sub-TLV described in the PPR Patent. In an embodiment, the sub-TLVs for the various attributes 240A-N described in <FIG> may be included in the OSPFv2 or OSPFv3 PPR Attribute Sub-TLV described in the PPR Patent. In another embodiment, the sub-TLVs for the various attributes 240A-N described in <FIG> may be entirely new messages, or may be included in any other protocol by which NEs <NUM>-<NUM> transmit data.

Referring first to <FIG>, shown is an example of a bandwidth sub-TLV <NUM> including a type field <NUM>, a length field <NUM>, reserved bits <NUM>, a minimum bandwidth <NUM>, and a maximum bandwidth <NUM>. The type field <NUM> includes a value indicating that the bandwidth sub-TLV <NUM> includes bandwidth related information (e.g., bandwidth requirement <NUM>) associated with a resource to be reserved on the PPR <NUM>. The value carried in the bandwidth sub-TLV <NUM> may be assigned by the IANA. The length field <NUM> is <NUM> octets and defines a length of the bandwidth sub-TLV <NUM>. The reserved bits <NUM> are empty and reserved for future use.

The minimum bandwidth field <NUM> carries a bandwidth requirement <NUM> defining a minimum bandwidth (also referred to as committed information rate (CIR)) that is required on a link <NUM>-<NUM> and <NUM>-<NUM> attached to an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> for data packets (comprising the PPR-ID <NUM> of the PPR <NUM>) to be transmitted over the link <NUM>-<NUM> and <NUM>-<NUM> on the PPR <NUM>. The maximum bandwidth field <NUM> carries a bandwidth requirement <NUM> defining maximum bandwidth (also referred to as peak information rate (PIR)) that is required on a link <NUM>-<NUM> and <NUM>-<NUM> attached to an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> for data packets (comprising the PPR-ID <NUM> of the PPR <NUM>) to be transmitted over the link <NUM>-<NUM> and <NUM>-<NUM> on the PPR <NUM>. The minimum bandwidth and/or maximum bandwidth may be indicated in the minimum bandwidth field <NUM> and/or maximum bandwidth field <NUM>, respectively, using the unit of megabits per second (Mbps). Although the bandwidth sub-TLV <NUM> includes fields <NUM> and <NUM> for both a minimum and maximum bandwidth, it should be appreciated that the bandwidth sub-TLV <NUM> may define only a minimum bandwidth, only a maximum bandwidth, or both a minimum and maximum bandwidth.

Referring next to <FIG>, shown is an example of a burst size sub-TLV <NUM> including a type field <NUM>, a length field <NUM>, reserved bits <NUM>, and a burst size field <NUM>. The type field <NUM> includes a value indicating that the burst size sub-TLV <NUM> includes burst size related information (e.g., burst size <NUM>) associated with a resource to be reserved on the PPR <NUM>. The value carried in the type field <NUM> may be assigned by the IANA. The length field <NUM> is <NUM> octets and defines a length of the burst size sub-TLV <NUM>. The reserved bits <NUM> are empty and reserved for future use.

The burst size field <NUM> carries a burst size <NUM>, which may define maximum burst size of a burst carried on a link <NUM>-<NUM> of the PPR <NUM>. A burst refers to an aggregation of data packets including the PPR-ID <NUM> of PPR <NUM>. The burst size <NUM> may be indicated in the burst size field <NUM> using the unit of <NUM> (K) bytes.

Referring next to <FIG>, shown is an example of a per-hop queuing latency size sub-TLV <NUM> including a type field <NUM>, a length field <NUM>, reserved bits <NUM>, a T flag <NUM>, a flags field <NUM>, and a latency field <NUM>. The type field <NUM> includes a value indicating that the per-hop queuing latency size sub-TLV <NUM> includes per-hop queuing latency information (e.g., bounded latency <NUM>) associated with an NE <NUM>-<NUM> on the PPR <NUM>. The value carried in the type field <NUM> may be assigned by the IANA. The length field <NUM> is <NUM> octets and defines a length of the per-hop queuing latency size sub-TLV <NUM>. The reserved bits <NUM> are empty and reserved for future use.

The T flag <NUM>, also referred to as the T bit, is set to <NUM> if a bounded latency <NUM> carried in the latency field <NUM> is expressed in milliseconds. The T flag <NUM> is set to <NUM> if a bounded latency <NUM> carried in the latency field <NUM> is expressed in microseconds. The flags field <NUM> is one octet and includes one or more flags related to the bounded latency <NUM> carried the latency field <NUM>. The latency field <NUM> carries a bounded latency <NUM> defined as an expected maximum queuing latency for each NE <NUM>-<NUM> on the PPR <NUM>. In an embodiment, data packets (including the PPR-ID <NUM> of the PPR <NUM>) may only be transmitted to or received by an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> if a queuing latency at that NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> is less than the maximum queuing latency carried by the latency field <NUM>. In an embodiment, when an attribute 240A-N carries an expected maximum queuing latency, a minimum bandwidth should also be carried in the attributes 240A-N.

Referring next to <FIG>, shown is an example of a lifetime sub-TLV <NUM> including a type field <NUM>, a length field <NUM>, reserved bits <NUM>, a flags field <NUM>, and a lifetime field <NUM>. The type field <NUM> includes a value indicating that the lifetime sub-TLV <NUM> includes lifetime related information (e.g., lifetime <NUM>) associated with the PPR <NUM>. The value carried in the type field <NUM> may be assigned by the IANA. The length field <NUM> is <NUM> octets and defines a length of the lifetime sub-TLV <NUM>. The flags field <NUM> is one octet and carries data associated with the lifetime <NUM> included in the lifetime field <NUM>. The lifetime field <NUM> includes the lifetime <NUM>, or the time period during which resources are reserved along a PPR <NUM>, which can only be reset upon receiving a state refresh (another advertisement <NUM> with the same PPR information <NUM>). The reserved bits <NUM> are empty and reserved for future use.

Therefore, <FIG> and <FIG> describe the attributes 240A-N that are included in the PPR information <NUM> advertised for a PPR <NUM> and different ways to encode the attributes 240A-N into the advertisement <NUM>. In an embodiment, the attributes 240A-N may be modified or updated by sending another advertisement <NUM> including modified attributes 240AN in the PPR information <NUM>. For example, the NE <NUM>-<NUM> that originally sent the advertisement <NUM> including the PPR information <NUM> may receive modified attributes 240A-N for the PPR <NUM> (from either an operator of the network <NUM> or a central entity <NUM>). In this case, the NE <NUM>-<NUM> may send another advertisement <NUM> with the same PPR information <NUM>, except including the modified attributes 240A-N instead of the originally sent attributes 240A-N. The receiving NEs <NUM>-<NUM> that receive the modified attributes 240A-N may update the locally stored forwarding database <NUM> to reflect the received modified attributes 240A-N.

<FIG> are diagrams illustrating an example of a node status <NUM>, and fields within the node status <NUM>, sent by NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> to every other NE <NUM>-<NUM> in the area 150A-B or the network <NUM> and the central entity <NUM> according to various embodiments of the disclosure. As described above, a node status <NUM> is a message indicating whether a resource for the PPR <NUM> has been successfully reserved according to the attribute 240A-N included in the PPR information <NUM>.

As shown in <FIG>, the node status <NUM> includes a node ID <NUM> identifying the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> sending the node status <NUM>. The node ID <NUM> may be a label, address, or ID that uniquely identifies the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> sending the node status <NUM>.

The node status <NUM> also includes a resource reservation status <NUM>. The resource reservation status <NUM> may include one or sub-TLVs and one or more flags indicating a status of certain resources that have been reserved according to an attribute 240A-N (also referred to herein as "attribute <NUM>") specified for the PPR <NUM>. An example of a sub-TLV that may be included in the resource reservation status <NUM> is shown and described below with reference to <FIG>. Examples of flags that may be included in the resource reservation status <NUM> is shown and described below with reference to <FIG>.

<FIG> shows an example of a node status TLV <NUM> that may be included in the resource reservation status <NUM> according to various embodiments of the disclosure. In an embodiment, the node status TLV <NUM> may be a new top level IS-IS TLV, OSPFv2 TLV, or OSPFv3 TLV defined to indicate the status of PPR TE resource reservation by each NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM>. In this embodiment, the node status TLV <NUM> is generated by an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> which performs the reservation of resources. In another embodiment, the node status TLV <NUM> is an entirely new message, or can be encoded into another protocol by which NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are configured to transmit data.

The node status TLV <NUM> includes a type field <NUM>, a length field <NUM>, reserved bits <NUM>, and one or more sub-TLVs <NUM>. The type field <NUM> carries a value assigned by the IANA indicating that the node status TLV <NUM> includes data regarding a status of resources reserved for a PPR <NUM>. For example, the value may be assigned from the IS-IS top level TLV registry. The length field <NUM> includes a value indicating a total length of the node status TLV <NUM> in bytes. The sub-TLVs <NUM> are further described below with reference to <FIG>. The reserved bits <NUM> are empty and reserved for future use.

Referring next to <FIG>, shown is an example of a sub-TLV <NUM> included in a node status <NUM> according to various embodiments of the disclosure. As shown by <FIG>, the sub-TLV <NUM> includes a type field <NUM>, a length field <NUM>, a PPR-ID type field <NUM>, a PPR-ID length field <NUM> (shown as PPR-ID Len in <FIG>), a PPR-ID value field <NUM>, and a <NUM>-bit status bit-field <NUM>. The type field <NUM> carries a value assigned by the IANA indicating that the sub-TLV <NUM> includes data regarding a status of resources reserved for a PPR <NUM>. The length field <NUM> includes a value indicating a total length of the sub-TLV <NUM> in bytes. The PPR-ID type field <NUM> carries a value indicating a type of PPR-ID <NUM> carried in the PPR-ID value field <NUM> (e.g., whether the PPR-ID <NUM> is an MPLS label, an IPV4 address, an IPv6 address, etc.). The PPR-ID length field <NUM> carries a length of the PPR-ID value field <NUM>. The PPR-ID value field <NUM> carries the PPR-ID <NUM> identifying the PPR <NUM>. The <NUM>-bit status bit-field <NUM> includes various flags describing the status of resources reserved on the PPR <NUM> and is further described below with reference to <FIG>.

Referring next to <FIG>, shown is an example of a <NUM>-bit status bit-field <NUM> included in a node status TLV <NUM> of a node status <NUM> according to various embodiments of the disclosure. The <NUM>-bit status bit-field <NUM> includes a B flag <NUM>, an S flag <NUM>, an L flag <NUM>, a T flag <NUM>, reserved bits <NUM>, and an E flag <NUM>.

The B flag <NUM>, also referred to as Bit-<NUM> or the B Bit, indicates whether bandwidth requirement <NUM> (defined as either the minimum or maximum bandwidth reservation for a resource on the PPR <NUM>) has been reserved by the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> sending the node status <NUM>. The S flag <NUM>, also referred to as Bit-<NUM> or the S Bit, is set to indicate whether the burst size <NUM> handling on the PPR <NUM> has been set by the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> sending the node status <NUM>. The L flag <NUM>, also referred to as Bit-<NUM> or the L Bit, is set to indicate whether a bounded latency <NUM> defined as a per-hop maximum queuing for the PPR <NUM> has been set by the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> sending the node status <NUM>. The T flag <NUM>, also referred to as Bit-<NUM> or the T Bit, is set to indicate whether a lifetime <NUM> or expiration timer for the PPR <NUM> has been set by the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> sending the node status <NUM>. The reserved bits <NUM> are empty and reserved for future use. The E flag <NUM>, also referred to as Bit-<NUM> or the E Bit, is set to indicate that one more <NUM> bit status field(s) follows the E flag <NUM>.

In an embodiment, one of the NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> on the PPR <NUM> may identify that one of the elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> on the PPR <NUM> is unavailable or failed. In this case, an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> adjacent to or attached to the unavailable element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> may notify the headend NE <NUM>-<NUM> that sent the original advertisement <NUM> of the unavailable element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. The NE <NUM>-<NUM> adjacent to or attached to the unavailable element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> may notify the NE <NUM>-<NUM> in the network <NUM> acting as the BGP-LS speaker, such that the BGP-LS speaker notifies the central entity <NUM> of the unavailable element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM>. In an embodiment, the central entity <NUM>, which stores the network topology of network <NUM>, determines another PPR <NUM> without the unavailable element <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> satisfies the same attributes 240A-N as the original PPR <NUM>, and transmits PPR information <NUM> related to the newly determined PPR <NUM> to a headend NE <NUM>-<NUM>. The headend NE <NUM>-<NUM> again floods the area 150A-B or the network <NUM> with the PPR information <NUM> describing the newly determined PPR <NUM>.

<FIG> are diagrams illustrating an example of usage statistics <NUM> collected by NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM>, and fields within the usage statistics <NUM>, according to various embodiments of the disclosure. As described above, usage statistics <NUM> refers to statistics regarding the usage of various resources along the PPR <NUM>. In an embodiment, the usage statistics <NUM> may be flooded through the respective area 150A-B or network <NUM> until the usage statistics <NUM> reaches a BGP-LS speaker within the respective area 150A-B or network <NUM>. The BGP-LS speaker then transmits the usage statistics <NUM> to the central entity <NUM>, such that the central entity <NUM> may modify the PPR <NUM> if necessary. In another embodiment, the NE <NUM>-<NUM> may directly send the usage statistics <NUM> to the central entity <NUM>, such that the central entity <NUM> may modify the PPR <NUM> if necessary.

As shown in <FIG>, the usage statistics <NUM> may include a node ID <NUM> identifying the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM> sending the usage statistics <NUM>. The node ID <NUM> may be a label, address, or ID that uniquely identifies the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> sending the usage statistics <NUM>. The usage statistics <NUM> also includes a PPR-ID <NUM> identifying the PPR <NUM> being monitored and described by the usage statistics <NUM>.

The usage statistics <NUM> also includes collected network usage statistics <NUM>, which may include a queue delay <NUM> and a bandwidth statistics <NUM>. The queue delay <NUM> indicates a queuing or transmission delay occurring at an NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> on the PPR <NUM>. The bandwidth statistics <NUM> includes bandwidth related statistics of the PPR <NUM>, such as utilized bandwidth along a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>, unutilized bandwidth along a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>, or a bandwidth violation along a link <NUM>-<NUM> and <NUM>-<NUM> of the PPR <NUM>. A bandwidth violation can occur because of local failures or due to resource exhaustion set aside for a PPR <NUM>. Examples of TLVs or sub-TLVs carrying collected network usage statistics <NUM> included in the usage statistics <NUM> is shown and described below with reference to <FIG>.

Referring next to <FIG>, shown is an example of a per-PPR queueing delay sub-TLV <NUM> that may be included in the usage statistics <NUM> according to various embodiments of the disclosure. In an embodiment, the per-PPR queueing delay sub-TLV <NUM> may be a new sub-TLV included in the IETF RFC <NUM>, entitled "<NPL>. In an embodiment, the per-PPR queueing delay sub-TLV <NUM> may be a new message for an existing protocol or a new protocol.

The per-PPR queueing delay sub-TLV <NUM> includes a type field <NUM>, a length field <NUM>, reserved bits <NUM>, an average queue delay variation field <NUM>, a PPR-ID type field <NUM>, a PPR-ID length field <NUM> (shown as PPR-ID Len in <FIG>), and a PPR-ID value field <NUM>. The type field <NUM> carries a value assigned by the IANA indicating that the per-PPR queueing delay sub-TLV <NUM> includes data regarding the queue delay <NUM> occurring at NEs <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> along a PPR <NUM>. The length field <NUM> includes a value indicating a total length of the per-PPR queueing delay sub-TLV <NUM> in bytes. The reserved bits <NUM> are set to <NUM> and reserved for future use.

The average queue delay variation field <NUM> is a <NUM> bit field that carries the queue delay <NUM>, which is an average PPR queue delay variation over a configurable interval in microseconds. The average PPR queue delay variation is encoded into the average queue delay variation field <NUM> as an integer value. When the average queue delay variation is set to <NUM> in the average queue delay variation field <NUM>, the NE <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> sending the usage statistics <NUM> has not measured the average queue delay variation. The PPR-ID type field <NUM>, the PPR-ID length field <NUM>, and the PPR-ID value field <NUM> are similar to the PPR-ID type field <NUM>, the PPR-ID length field <NUM>, and the PPR-ID value field <NUM>, respectively.

Referring next to <FIG>, shown is an example of a unidirectional utilized PPR bandwidth sub-TLV <NUM> that may be included in the usage statistics <NUM> according to various embodiments of the disclosure. In an embodiment, the unidirectional utilized PPR bandwidth sub-TLV <NUM> may be a new sub-TLV included in the IETF RFC <NUM>, entitled "<NPL>. In an embodiment, the unidirectional utilized PPR bandwidth sub-TLV <NUM> may be a new message for an existing protocol or a new protocol.

The unidirectional utilized PPR bandwidth sub-TLV <NUM> includes a type field <NUM>, a length field <NUM>, a utilized bandwidth field <NUM>, a PPR-ID type field <NUM>, a PPR-ID length field <NUM> (shown as PPR-ID Len in <FIG>), and a PPR-ID value field <NUM>. The type field <NUM> carries a value assigned by the IANA indicating that the unidirectional utilized PPR bandwidth sub-TLV <NUM> includes bandwidth statistics <NUM> regarding a utilized bandwidth of a link <NUM>-<NUM> and <NUM>-<NUM> reserved along a PPR <NUM>. The length field <NUM> includes a value indicating a total length of the unidirectional utilized PPR bandwidth sub-TLV <NUM> in bytes.

The utilized bandwidth field <NUM> is a field that carries the bandwidth statistic <NUM>, which may be bandwidth utilization per PPR <NUM> (or per PPR-ID <NUM>) on a link link <NUM>-<NUM> and <NUM>-<NUM> along a PPR <NUM>, forwarding adjacency, or bundled link floating-point format with units of bytes per second. The PPR-ID type field <NUM>, the PPR-ID length field <NUM>, and the PPR-ID value field <NUM> are similar to the PPR-ID type field <NUM>, the PPR-ID length field <NUM>, and the PPR-ID value field <NUM>, respectively.

<FIG> is a method <NUM> for implementing resource reservation and maintenance on a PPR <NUM> according various embodiments of the disclosure. In an embodiment, method <NUM> may be performed by a headend or ingress NE <NUM>-<NUM> in a network <NUM>. In an embodiment, method <NUM> may be performed after a central entity <NUM> obtains and transmits PPR information <NUM> to an NE <NUM>-<NUM> in the network <NUM>.

At step <NUM>, an advertisement <NUM> comprising PPR information <NUM> describing a path from a source to a destination is received. For example, Rx <NUM> receives the PPR information <NUM> from the central entity <NUM> or another NE <NUM>-<NUM>. The PPR information <NUM> includes a PPR-ID <NUM> and an attribute <NUM> associated with a resource to be reserved on the PPR <NUM>. In an embodiment, the source may refer to the source <NUM> or an ingress NE <NUM> on the PPR <NUM>. In an embodiment, the destination may refer to the destination <NUM> or the egress NE <NUM> on the PPR <NUM>.

At step <NUM>, the advertisement <NUM> comprising the PPR-ID <NUM> and the attributes <NUM> specified for a PPR <NUM> are transmitted to another NE in the network <NUM>. For example, Tx <NUM> transmits the advertisement <NUM> comprising the PPR-ID <NUM> and the attributes <NUM> specified for a PPR <NUM> that are transmitted to another NE in the network <NUM>.

At step <NUM>, a local forwarding database <NUM> is updated to include the PPR information <NUM> in association with the destination in response to the NE <NUM>-<NUM> being identified in the PPR information <NUM>. For example, local forwarding database <NUM> is updated in the memory <NUM> to include the attributes <NUM> in association with the PPR-ID <NUM>.

<FIG> is a method <NUM> for implementing resource reservation and maintenance on a PPR <NUM> according various embodiments of the disclosure. In an embodiment, method <NUM> may be performed by an intermediate NE <NUM>-<NUM> (referred to with reference to this method <NUM> as the first NE <NUM>-<NUM>) in a network <NUM>.

At step <NUM>, an advertisement <NUM> comprising PPR information <NUM> describing a path from a source to a destination is received from another NE <NUM>-<NUM>. For example, Rx <NUM> receives the PPR information <NUM> from the central entity <NUM> or another NE <NUM>-<NUM>. The PPR information <NUM> includes a PPR-ID <NUM> and an attribute <NUM> associated with a resource to be reserved on the PPR <NUM>. In an embodiment, the source may refer to the source <NUM> or an ingress NE <NUM> on the PPR <NUM>. In an embodiment, the destination may refer to the destination <NUM> or the egress NE <NUM> on the PPR <NUM>.

At step <NUM>, a local forwarding database <NUM> is updated to include the PPR information <NUM> in association with the destination or egress NE in response to the first NE <NUM>-<NUM> being identified in the PPR information <NUM>. For example, local forwarding database <NUM> is updated in the memory <NUM> to include the attributes <NUM> in association with the PPR-ID <NUM>.

At step <NUM>, the PPR <NUM> is provisioned at the first NE <NUM>-<NUM> based on the attribute <NUM> in the PPR information <NUM>. For example, the resource associated with the attribute <NUM> is reserved for the PPR <NUM> by the first NE <NUM>-<NUM>.

At step <NUM>, a node status <NUM> of the first NE <NUM>-<NUM> is updated to indicate whether the resource for the PPR <NUM> has been successfully reserved according to the attribute <NUM> included in the PPR information <NUM>. For example, the network configuration module <NUM> is executed by the processor <NUM> to update the node status <NUM> of the first NE <NUM>-<NUM> to indicate whether the resource for the PPR <NUM> has been successfully reserved according to the attribute <NUM> included in the PPR information <NUM>.

At step <NUM>, the node status <NUM> is transmitted to the central entity <NUM>. For example, Tx <NUM> transmits the node status <NUM> to the central entity <NUM>.

<FIG> shows an apparatus <NUM> for implementing resource reservation and maintenance on a PPR <NUM> according various embodiments of the disclosure. The apparatus <NUM> comprises a means for receiving <NUM>, a means for updating <NUM>, and a means for transmitting <NUM>. The means for receiving <NUM> comprises a means to receive an advertisement <NUM> comprising PPR information <NUM> describing a path from a source to a destination. The PPR information <NUM> includes a PPR-ID <NUM> and an attribute <NUM> associated with a resource to be reserved on the PPR <NUM>. In an embodiment, the source may refer to the source <NUM> or an ingress NE <NUM> on the PPR <NUM>. In an embodiment, the destination may refer to the destination <NUM> or the egress NE <NUM> on the PPR <NUM>. The means for updating <NUM> comprises a means to update a local forwarding database <NUM> to include the PPR information <NUM> in association with the destination. The means for transmitting <NUM> comprises a means to transmit the advertisement <NUM> comprising the PPR-ID <NUM> and the attributes <NUM> specified for a PPR <NUM> to another NE <NUM>-<NUM> in the network <NUM>.

Claim 1:
A method implemented by a network element, NE, (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) in a network (<NUM>), comprising:
receiving (<NUM>), by the NE (<NUM> - <NUM>), an advertisement (<NUM>) comprising preferred path route, PPR, information (<NUM>) describing a path from an ingress NE (<NUM>) to an egress NE (<NUM>) in the network (<NUM>), the PPR information (<NUM>) comprising a PPR identifier, PPR-ID, (<NUM>) and an attribute (<NUM>) associated with a resource to be reserved on the PPR (<NUM>);
transmitting (<NUM>), by the NE (<NUM> - <NUM>), the advertisement (<NUM>) comprising the PPR-ID (<NUM>) and the attribute (<NUM>) associated with the resource to be reserved on the PPR (<NUM>) to another NE (<NUM> - <NUM>) in the network (<NUM>); monitoring, by the NE (<NUM>- <NUM>), usage statistics (<NUM>) related to the resource reserved for the PPR (<NUM>) after the resource is successfully reserved on the PPR (<NUM>);
transmitting, by the NE (<NUM>- <NUM>), node resource capabilities (<NUM>) including one or more flags indicating usage statistics (<NUM>), which the NE (<NUM> - <NUM>) is capable of monitoring for the resource reserved in the network (<NUM>), to a central entity (<NUM>) of the PPR (<NUM>); and updating (<NUM>), by the NE (<NUM>-<NUM>), a local forwarding database (<NUM>) to include the PPR information (<NUM>) in association with the egress NE (<NUM>) in response to the NE (<NUM> - <NUM>) being identified in the PPR information (<NUM>).