WO2020264578A1

WO2020264578A1 - Automatic allocation of ipv6 preferred path routing identifiers

Info

Publication number: WO2020264578A1
Application number: PCT/US2020/070195
Authority: WO
Inventors: Stewart Bryant; Uma S. Chunduri; Toerless Eckert
Original assignee: Futurewei Technologies, Inc.
Priority date: 2019-06-28
Filing date: 2020-06-26
Publication date: 2020-12-30

Abstract

A computer implemented method comprises sending a data packet from a network source node via a preferred path routing (PPR) domain of the communication network. The data packet includes a preferred path routing identifier (PPR-ID) in a packet destination address field that identifies a path along network nodes of the communication network. The PPR-ID includes a destination node identifier and a source node identifier.

Description

AUTOMATIC ALLOCATION OF IPV6 PREFERRED PATH ROUTING

IDENTIFIERS

CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This Application claims priority from U.S. Provisional

Application No. 62/868,501, filed June 28, 2019, the contents of which are incorporated herein by reference in their entirety.

BACKGROUND

[0002] Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), a communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion.

[0003] Devices on the Internet are assigned a unique IP address for identification and location definition. With the rapid growth of the Internet after commercialization in the 1990s, it became evident that far more addresses would be needed to connect devices than were available in the IPv4 address space. By 1998, the Internet Engineering Task Force (IETF) had formalized the successor protocol. IPv6 uses a 128-bit address, theoretically allowing 2¹” or

approximately 3.4x10” addresses. The actual number is slightly smaller, as multiple ranges are reserved for special use or completely excluded from use. The total number of possible IPv6 addresses is more than 7.9x10” times as many as possible with IPv4, which uses 32-bit addresses and provides approximately 4.3 billion addresses. The two protocols are not designed to be interoperable, complicating the transition to IPv6. However, several IPv6 transition mechanisms have been devised to permit communication between IPv4 and IPv6 hosts.

[0004] IPv6 permits hierarchical address allocation methods that facilitate route aggregation across the Internet, and thus limits the need for expansion of routing tables despite the expanded address space. The use of multicast addressing is expanded and simplified and provides additional optimization for the delivery of services. Device mobility, security, and configuration aspects were considered in the design of the IPv6 protocol.

SUMMARY

[0005] Various examples are now described to introduce a selection of concepts in a simplified form that are further described below in the detailed description. The Summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] A computer implemented method includes using a structured suffix to an IPv6 address as a Preferred Path Routing Identifier (PPR-ID) to simplify signaling requirements and avoid the need to signal sessions between sender and receiver. The structured suffix is flexible on a per network basis, and multiple versions of the structured suffix can run concurrently within a PPR domain.

[0007] According to one aspect of the present disclosure, there is provided a network node of a communication network. The network node comprises processing circuitry configured to encode a data packet to send via the network, wherein the data packet includes a preferred path routing identifier

(PPR-ID) in a packet destination address field that identifies a path deployed on the network nodes of the communication network. The PPR-ID includes a destination node identifier, and a source node identifier.

[0008] Optionally, in the preceding aspect, another implementation of the aspect provides a PPR-ID that includes a first path instance identifier of multiple path instance identifiers that identify specific network paths for the data packet from the source node to the destination node.

[0009] Optionally, in the preceding aspect, another implementation of the aspect provides the higher order bits of the PPR-ID including the destination node identifier and lower order bits of the PPR-ID including the path instance identifier.

[0010] Optionally, in any of the preceding aspects, another

implementation of the aspect provides a packet destination address field that includes a routing prefix and a PPR suffix, and the PPR-ID is included in the PPR suffix.

[0011] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry configured to encode the data packet to include, in the packet destination address field, an identifier of a network programming action appended to the PPR suffix that identifies an action to be performed on the data packet when it is received at the destination node.

[0012] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry configured to encode the PPR-ID using a node identifier space for the destination node identifier that is disjoint from the node identifier space for the source node identifier.

[0013] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry is configured to encode the PPR-ID using an identifier of a root node of a PPR tree as the destination node identifier.

[0014] Optionally, in any of the preceding aspects, another

implementation of the aspect provides the communication network being a PPR domain of an Internet Protocol version 6 (IPv6) network.

[0015] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry is configured to decode a first data packet received via the network, wherein the first data packet includes a first PPR-ID, decode a second data packet received via the network, wherein the second data packet includes a second PPR-ID, and apply a network resource to the second data packet different from a network resource applied to the first data packet.

[0016] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry configured to generate the PPR-ID for the data packet according to a network protocol when network node numbers for the communication network are advertised.

[0017] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry configured to generate the PPR-ID for the data packet without receiving information from a central network controller.

[0018] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry configured to generate the PPR-ID for the data packet without receiving information from the destination node in addition to the destination node identifier.

[0019] According to another aspect of the present disclosure, there is provided a system including a plurality of network nodes of the network node of any of the preceding aspects. A PPR-ID generated by a network node of the plurality of network nodes is guaranteed to be unique among PPR-IDs generated by the plurality of network nodes.

[0020] According to another aspect of the present disclosure, there is provided a computer implemented method of sending data using a

communication network. The method comprises sending a data packet from a network source node via a preferred path routing (PPR) domain of the communication network and including a preferred path routing identifier (PPR- ID) in a packet destination address field of the data packet. The PPR-ID identifies a path deployed on network nodes of the communication network, and the PPR-ID includes a destination node identifier and a source node identifier.

[0021] Optionally, in the preceding aspect, another implementation of the aspect provides including a first path instance identifier of multiple path instance identifiers in the destination address field that identify specific network paths for the data packet from the source node to the destination node.

[0022] Optionally, in any of the preceding aspects, another

implementation of the aspect provides sending a data packet that includes the destination node identifier in higher order bits of the PPR-ID and includes the path instance identifier in lower order bits of the PPR-ID include.

[0023] Optionally, in any of the preceding aspects, another

implementation of the aspect provides sending a data packet that includes a routing prefix and a PPR suffix in the packet destination address field and including the PPR-ID in the PPR suffix.

[0024] Optionally, in any of the preceding aspects, another

implementation of the aspect provides sending a data packet that includes an identifier of a network programming action appended to the PPR suffix in the packet destination address field, wherein the identifier of the network programming action identifies an action to be performed on the data packet when it is received at the destination node.

[0025] Optionally, in any of the preceding aspects, another

implementation of the aspect provides selecting an identifier value for the destination node identifier from a first node identifier space that is disjoint from a second node identifier space used to select an identifier value for the source node identifier.

[0026] Optionally, in any of the preceding aspects, another

implementation of the aspect provides sending a data packet that includes an identifier of a root node of a PPR tree as the destination node identifier.

[0027] Optionally, in any of the preceding aspects, another

[0028] Optionally, in any of the preceding aspects, another

implementation of the aspect provides sending a data packet that includes a path instance identifier unique to a destination node identifier and source node identifier pair, and not unique to the communication network.

[0029] Optionally, in any of the preceding aspects, another

implementation of the aspect provides routing a first data packet using a first PPR-ID that includes a first destination node identifier, a first source node identifier, and a first path instance identifier, routing a second data packet using a second PPR-ID that includes the first destination node identifier, the first source node identifier, and a second path instance identifier, and applying a network resource to the second data packet different from a network resource applied to the first data packet.

[0030] Optionally, in any of the preceding aspects, another

implementation of the aspect provides including a path instance identifier in the destination address field that identifies a multi-point to point network path for the data packet.

[0031] Optionally, in any of the preceding aspects, another

implementation of the aspect provides including a path instance identifier in the destination address field that identifies a multi-point to multi-point network path for the data packet.

[0032] Optionally, in any of the preceding aspects, another

implementation of the aspect provides generating the PPR-ID for the data packet according to a network protocol when network node numbers for the communication network are advertised.

[0033] Optionally, in any of the preceding aspects, another

implementation of the aspect provides generating the PPR-ID for the data packet without receiving information from a central network controller.

[0034] Optionally, in any of the preceding aspects, another

implementation of the aspect provides generating the PPR-ID for the data packet without receiving information from the destination node in addition to the destination node identifier.

[0035] According to another aspect of the present disclosure, there is provided a computer-readable storage medium, storing instructions for execution by a processing circuitry of a computing device to cause the processing circuitry to perform operations. The operations include encoding a data packet to send via a communication network, wherein the data packet includes a preferred path routing identifier (PPR-ID) in a packet destination address field. The PPR-ID includes a destination node identifier; a source node identifier; and a first path instance identifier of multiple path instance identifiers in the destination address field that identify specific network paths for the data packet from the source node to the destination node.

[0036] Optionally, in the preceding aspect, another implementation of the aspect provides instructions to cause the processing circuitry to include a routing prefix and a PPR suffix in the packet destination address field and include the PPR-ID in the PPR suffix.

[0037] Optionally, in any of the preceding aspects, another

implementation of the aspect provides instructions to cause the processing circuitry to encode the data packet to include, in the packet destination address field, an identifier of a network programming action appended to the PPR suffix, wherein the identifier of the network programming action identifies an action to be performed on the data packet when it is received at the destination node. [0038] Optionally, in any of the preceding aspects, another

implementation of the aspect provides including instructions to cause the processing circuitry to encode a data packet that includes an identifier of a root node of a PPR tree as the destination node identifier.

[0039] According to another aspect of the present disclosure, there is provided a network node of a communication network. The network node includes processing circuitry configured to receive network node identifier information, encode a transmit data packet according to a network protocol, wherein the encoded transmit data packet includes a PPR-ID that identifies a path of network nodes of the communication network, and send the encoded transmit data packet to another network node of the communication network.

[0040] Optionally, in the preceding aspect, another implementation of the aspect provides processing circuitry configured to generate the PPR-ID to include a destination node identifier and a source node identifier without information from a central controller of the communication network.

[0041] Optionally, in any of the preceding aspects, another

implementation of the aspect provides processing circuitry configured to generate the PPR-ID to further include a first path instance identifier of multiple path instance identifiers that identify specific network paths for the transmit data packet from the source node to the destination node.

[0042] According to another aspect of the present disclosure, there is provided a computer implemented method of sending data using a

communication network. The method comprises receiving network node identifier information at a network node of the communication network, encoding a transmit data packet according to a network protocol, wherein the encoded transmit data packet includes a preferred path routing identifier (PPR- ID) that identifies a path of network nodes of the communication network, and sending the encoded transmit data packet to another network node of the communication network.

[0043] Optionally, in the preceding aspect, another implementation of the aspect provides generating the PPR-ID to include a destination node identifier and a source node identifier without information from a central controller of the communication network. [0044] Optionally, in any of the preceding aspects, another

implementation of the aspect provides generating the PPR-ID to further include a first path instance identifier of multiple path instance identifiers that identify specific network paths for the transmit data packet from the source node to the destination node.

BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Some figures illustrating example embodiments are included with the text in the detailed description.

[0046] FIG. 1 is an illustration of network routing of a communication network to implement one or more example embodiments.

[0047] FIG. 2 is a diagram of a destination address structure with

Preferred Path Routing Identifier (PPR-ID) allocation system according to one or more example embodiments.

[0048] FIGS. 3-5 are illustrations of examples of Preferred Path Routing

(PPR) to implement one or more example embodiments.

[0049] FIG. 6 is a flow diagram of a method of sending data using a communication network to implement one or more example embodiments.

[0050] FIG. 7 is a block schematic diagram of a computer system to implement one or more example embodiments.

[0051] FIG. 8 is schematic diagram of a network device to implement one or more example embodiments.

DETAILED DESCRIPTION

[0052] In the following description, reference is made to the

accompanying drawings that form a part hereof and, in which are shown, by way of illustration, specific embodiments that may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized, and that structural, logical and electrical changes may be made without departing from the scope of the present invention. The following description of example embodiments is, therefore, not to be taken in a limited sense, and the scope of the present invention is defined by the appended claims. [0053] The functions or algorithms described herein may be

implemented in software in one embodiment. The software may consist of computer executable instructions stored on computer readable media or computer readable storage device such as one or more non-transitory memories or other type of hardware-based storage devices, either local or networked. Further, such functions correspond to modules which may be software, hardware, firmware or any combination thereof. Multiple functions may be performed in one or more modules as desired, and the embodiments described are merely examples. The software may be executed on a digital signal processor, ASIC, microprocessor, or other type of processor operating on a computer system, such as a personal computer, server or other computer system, turning such computer system into a specifically programmed machine.

[0054] The functionality can be configured to perform an operation using, for instance, software, hardware, firmware, or the like. For example, the phrase“configured to” can refer to a logic circuit structure of a hardware element that is to implement the associated functionality. The phrase “configured to” can also refer to a logic circuit structure of a hardware element that is to implement the coding design of associated functionality of firmware or software. The term“module” refers to a structural element that can be implemented using any suitable hardware (e.g., a processor, among others), software (e.g., an application, among others), firmware, or any combination of hardware, software, and firmware. The term“logic” encompasses any functionality for performing a task. For instance, each operation illustrated in the flowcharts corresponds to logic for performing that operation. An operation can be performed using software, hardware, firmware, or the like. The terms “component,”“system,” and the like may refer to computer-related entities, hardware, and software in execution, firmware, or combination thereof. A component may be a process running on a processor, an object, an execution, a program, a function, a subroutine, a computer, or a combination of software and hardware. The term“processor,” may refer to a hardware component, such as a processing unit of a computer system.

[0055] Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computing device to implement the disclosed subject matter. The term“article of manufacture,” as used herein, is intended to encompass a computer program accessible from any computer-readable storage device or media. Computer-readable storage media can include, but are not limited to, magnetic storage devices, e.g., hard disk, floppy disk, magnetic strips, optical disk, compact disk (CD), digital versatile disk (DVD), smart cards, flash memory devices, among others. In contrast, computer-readable media (i.e., not limited to storage media) may additionally include communication media such as transmission media for wireless signals and the like.

[0056] A communication network includes multiple network nodes communicating information using communication channels. A network node is a computing device able to receive, send, forward, and process information to other nodes of the network using paths of the network. Some examples of a network node include a network server, network router, a network hub, and a host computer. A network node can be a physical device or a virtual device. Traditionally, routing of packetized data in a network uses shortest path routing. A“hello” protocol between immediate neighbor nodes in the network can be used to form agencies and connected nodes, and links of the entire network are advertised using a flooding process. Shortest Path First route computation algorithms can be used to compute Next Hops (NHs) for all routes that are advertised in the network.

[0057] Segment Routing (SR) simplifies a network control plane by distributing Segment Identifiers (SIDs) for routing prefixes. Distributing the SIDs allows source routing to be achieved by representing the network path with stacked SIDs on the data packet without any changes to the network data plane.

[0058] In SR, segments and source routes can be computed by a controller with knowledge of the network topology and provision the network with end-to-end SR paths. The controller may be a Path Computation Element (PCE) or other type of Software Defined Networking (SDN) controller. Using a controller to compute segments and source routes allows for optimization and customization to paths that may be subject to different constraints. It also obviates the need for traditional multiprotocol label switching (MPLS) control plane protocols such as Label Distribution Protocol (LDP) or Resource

Reservation Protocol (RSVP), thereby reducing the number of protocols needed to be deployed in a network.

[0059] Despite its advantages, there are significant issues related to using SR. For instance, the overhead of using SIDs to represent paths can cause problems and may not be acceptable for certain network deployments. This overhead can become particularly pronounced for short packets (e.g., less than 100 bytes of payload), which are prevalent in applications such as Internet of Things (IoT) communications, Voice over IP (VoIP), telemedicine, and online gaming. The problem of using SIDs will be compounded in 5G networks where volumes of short size packets are expected that will be sensitive to significant overhead.

[0060] Another issue with SR is that while it allows a data packet to steer through a custom path, SR by itself it cannot guarantee that proper Quality of Service (QoS) along the path will be provided for a packet. The ability to manage resource reservations or to provide traffic engineering attributes is not within the scope of SR. A third issue is that SR cannot be applied to native IPv4/IPv6 data planes. While SR can be supported with MPLS without any changes in the data plane, use with IPv6 requires an SR Header (SRH) extension, whose support requires hardware upgrades across the network.

[0061] To address the issues with SR, Preferred Path Routing (PPR) avoids the representation of network paths as sequences of SIDs in packets that can lead to significant packet overhead due to significant path label stack depths.

In contrast, PPR limits the depth to a single path label.

[0062] In PPR, route computation is based on the specific path described along with the routing prefix as opposed to the shortest path towards the routing prefix. A difference between PPR and shortest path routing concerns how the next hop is computed. Instead of using the next hop of the shortest path towards the destination, the next hop towards the next node in the PPR path description is used. Any prefix advertised with a path description from any node in the network is called Preferred Path Route. A Preferred Path Route could be a Traffic Engineered (TE) path, a service chained path, or an explicitly provisioned Fast Re-Route (FRR) path. [0063] FRR is a technique that allows packet forwarding to continue in a network after a failure has occurred, but before the network has had time to reconverge. This is achieved by forwarding a packet on an alternative path that will not result in the packet looping. Because PPR provides a method of injecting explicit paths into the routing protocol, repair paths can be selectively injected to provide repair for critical links.

[0064] A Preferred Path Route can be signaled by a central controller which has the complete and dynamic view of the underlying network link state database with all links, nodes, adjacencies, and TE information. A Preferred Path Route can also be signaled by an operator by statically configuring the Preferred Path Route on a node in the network. Because paths and path identifiers can be computed and controlled by a controller and not a routing protocol, PPR allows the deployment of any paths that network operators prefer, which may not necessarily be the shortest paths.

[0065] A PPR path can be described using a list of segments as defined in SR for the data planes as defined by SR. However, a PPR path description is not limited to SR and a PPR path can be described using simple IPv6 Addresses for native IP data planes. For this reason, an element in the path description is called a PPR Identifier (PPR-IDs). PPR-IDs, like SR SIDs, can represent topological elements like links/nodes, backup nodes, as well as non-topological elements such as a service, function, or context on a particular node.

[0066] IPv6 addresses are represented as eight groups, separated by colons, of four hexadecimal digits. The full representation may be simplified by several methods of notation. For example

2001:0db8:0000:0000:0000:8a2e:0370:7334 becomes

2001 :db8::8a2e:370:7334.

[0067] In using PPR over an IPv6 network, one can use an IPv6 address or IPv6 prefix as a PPR-ID. Normally this would be done by selecting an IPv6 address (or prefix) from a pool reserved for this purpose and allocating it to the task through configuration, network management or via an SDN controller.

[0068] FIG. 1 is an illustration of network routing using shortest path and using PPR. The nodes of the network include processing circuitry and one or more ports for connecting to the network. The processing circuitry can include one or more processors configured to perform the functions described by executing instructions stored in memory integral to the processor or operatively coupled to the processor.

[0069] FIG. 1 shows an IPv6 network in which the network nodes“Rx” are routers. The shortest path to reach destination node Rd from a source node Rs is via R1-R2-R3-R4-R5, with all metrics set to value 1, except links between Rs to R6 and R8 to R12, which have a link metric of value 10. By signaling a PPR path Rs-R6-R7-R8-R12-R13-R14-Rd with a PPR- ID set to an IPv6 address 2001::1, any IPv6 packet with destination IP address set to 2001::1 would be steered along the PPR path. A destination node (e.g., node Rd) could be assigned an unstructured IPv6 prefix instead of an IPv6 address. This way, multiple PPR-IDs can be established in a forwarding table across the network for traffic terminating at node Rd on a PPR path from possibly same or different ingress nodes.

[0070] A PCE can compute and signal a PPR path. The PCE can be run on a network node itself (i.e., in a decentralized mode (e.g., pre-PCE initiated Language Server Protocol (LSP) and controller mode)). In this case, once PCE computes the dynamic path with certain operator inputs, signaling the path with a PPR-ID needs operator intervention for setting the PPR-ID appropriately at the egress of the path. For a node doing FRR computations (using proprietary algorithms or standardized algorithms like Remote Loop-Free Alternate (RLFA) or encapsulation using Not- VIA addressing), alternate paths need to be signaled in the network automatically to prepare for the failure. Automatic setting of the PPR-ID and automatic signaling of alternate paths in the event of failure are not currently possible.

[0071] Additionally, the path of a packet is an arbitrary path established by the network to meet the user needs. The PPR-ID is used to specify that path and, in the case of an IPv6 network, the PPR-ID uses the destination IP address field of the packet. The packet may be encapsulated with an outer IPv6 destination address field set to PPR-ID, or the original IPv6 address may be carried using some other mechanism However, a destination may need multiple PPR-IDs. Also, there may be situations where there are gaps in the PPR path. [0072] This approach, in which every entity in a distributed network design needs to ask for every PPR-ID it needs, does not scale as well as a system that delegates that operation to the network. An improved approach is to use a structured IPv6/PPR-ID allocation design to support delegation of PPR-ID allocation. The IPv6 address space is sufficiendy large that it is not necessary to husband each address, as it is in IPv4 or Ethernet. A structured approach to the design of the address suffix allows the network to delegate the selection of address to the network itself and still provide the advantages over using the list of path segments as in SR.

[0073] FIG. 2 is a diagram of an example of a destination address structure based PPR-ID allocation for an IPv6 network. A data packet is routed in the IPv6 network using the destination address structure. The address is 128 bits and includes a Prefix and a PPR suffix. The Prefix is X bits (e.g., 64 bits) that can include bits for a Routing Prefix and a Subnet Identifier (ID). The PPR suffix is included after the Prefix in the remaining (128 - X) bits. The PPR suffix includes a Destination field to identify the network destination node for the packet, a Source field to identify the network source node sending the packet, and an Instance field to identify the instance of communication between the source and destination node pair. An optional Program field can follow the

PPR suffix for an optional network programming instruction to be applied to the packet.

[0074] The destination node is the network node to which the data packet is addressed within the PPR domain. The network node may be a server or a router. The node number for the destination node can be assigned by the network management and configuration system or by an SDN controller. The node number is normally advertised in the routing protocol that is supporting PPR, but the node number may be made known to other nodes and controllers of the network by any suitable means. The number of bits needed in the PPR suffix for the destination node depends on the size of the node space, which is matter for the network operator to decide. Allocating 16 bits of the PPR suffix for the destination node number may be a satisfactory default and would be sufficient for most networks. As shown in FIG. 2, the destination node number is placed in the higher order bits of the PPR suffix. Placing the node number in the higher order bits assists with address aggregation.

[0075] FIG. 3 is an illustration of an example of PPR. The destination address structure includes the node number for the source node sending the data packet within the PPR domain. The example in FIG. 3 is useful to show why a source-specific PPR-ID is desirable. The example shows two paths (with preferred path routing identifiers PPR-ID 1, PPR-ID2) represented by lines and each path starts from a different source node (Source 1, Source 2) and ends at the same destination node (Destination). The lines represent links and routers of the network as in the example of FIG. 1. Where the lines intersect represents a common router in the two paths.

[0076] The path from a source node to a given destination node may be source specific due to the need for the allocation of specific resources to a service, or due to the need to constrain the physical path for reasons such as security. The path from one source node to the destination node may intersect the path from another source node and pass through common routers. The PPR- ID therefore may need to be distinct for each source-destination pair to avoid just sending the data packets forward in the same path when the data packets pass through a common router. Using the source node in the PPR-ID provides uniqueness to PPR-ID1 and PPR-ID2 for the paths. Grouping of network nodes to a common PPR-ID may be performed if the grouping suits the needs of the application and the conservation of resources in the network.

[0077] The node number for the source node can be assigned by the network management and configuration system or by an SDN controller.

Alternatively, it could be automatically derived using a method similar to the automatic nickname allocation method described in Internet Engineering Task Force (IETF) Specification RFC 6325. The node number for the source node is normally from the same node identifier space as the destination node and would be made known to other nodes and controllers of the network by the means used for the destination node. The identifier node space for the source nodes may be a node space parallel to the node space of the destination nodes or may be a node space disjoint to the destination node space. The number of bits needed in the PPR suffix for the source node would generally be the same as for the destination node, and allocating 16 bits of the PPR suffix for the source node number would be a satisfactory default. As shown in FIG. 2, the source node number is placed in the higher order bits of the PPR suffix (but not higher than the destination node number) to support address aggregation.

[0078] FIG. 4 is an illustration of another example of PPR. The destination address structure in FIG. 2 includes an Instance identifier to distinguish between different path instances between the same source-destination pair. The example in FIG. 4 is useful to show why it is useful to have multiple instance identifiers for a source-destination pair in a PPR-ID. The example shows four paths PPR-ID 1 through PPR-ID4 represented by lines and each path starts from the same source node (Source 1) and ends at one of two destination nodes (Destination 1, Destination 2).

[0079] Two paths (PPR-ID1 , PPR-ID2) start at node Source 1 and end at node Destination 1. Each of paths PPR-ID 1, PPR-ID2 may be application specific and each of the paths may be treated differently (e.g., have different policies) and may need different resources. For example, PPR-ID 1 may be high bandwidth while PPR-ID2 needs deterministic latency. In further examples, each path may be associated with a different network slice, or each path may be associated with a different geographical constraint. Thus, multiple path instances for each source-destination pair is useful to distinguish between paths between the source-destination pair. The values of the instances for a given source-destination pair are unique, but the values can be reused for a different source-destination pair. For example, the two paths PPR-ID3 and PPR-ID4 start at node Sourcel and end at a different destination node (Destination 2). Because the source-destination node number pairs are different, the instance values unique to PPR-ID1, PPR-ID2 can be reused in paths PPR-ID3, PPR-ID4.

[0080] The value of an Instance identifier can be advertised in the routing protocol supporting PPR. Instance identifiers may be advertised as an instance base and the number of instances supported. The number of bits for the Instance identifier depends on the size of the number space or node space, but allocating 16 bits of the PPR suffix for the Instance identifier would be sufficient for most networks and would be a satisfactory default. A default instance number (e.g., zero) can be used to indicate that instance specific handling is not required. The Instance identifier can be placed in the lower order bits at the end of the PPR suffix but before the network programming field to support address aggregation.

[0081] The Instance identifier can be used to indicate an instance of a

PPR graph or tree. A PPR graph can specify a tree with paths from multiple source nodes to a destination node (e.g., a multi-point to point (MP2P) graph). The Instance identifier is unique to the tree instead of the source-destination pair. This allows a policy to be applied to the whole tree. A tree terminates on a unique destination node, so the Instance identifier would be unique to both the tree and the destination node. The same Instance identifier would be available for use in trees that terminate on different destination nodes. The Instance identifiers for trees may be in the same number space as Instance identifiers for source-destination pairs, or the Instance identifiers for trees may be have its own number space. The Instance identifier can also be used to indicate a graph from multiple source nodes to multiple destinations nodes (e.g., a multi-point to multipoint (MP2MP) graph).

[0082] FIG. 5 is an illustration of another example of PPR. The destination address structure in FIG. 2 can optionally include a network programming action after the PPR suffix. The network programming action is a network program function applied to the packet when the packet arrives at the destination node. Some examples of network program functions include endpoint functions, headend functions, and hash computations. The example in FIG. 5 shows a PPR path (PPR-ID1) with different network programming actions (FN1, FN2). In an example, the number of bits of the destination address structure allocated to the network programming action field may be 16. If network programming is not used, the number of bits may be zero, or the field may be set to a default value to indicate that the network program function is not used. In a network that supports both modes (i.e., programming for some paths and no programming for other paths) different address routing prefixes can be used to distinguish between the modes. The network programming action field can be wild carded if there is no requirement for a path difference for a group or there is no requirement for a difference between network program functions. [0083] The destination address structure techniques described herein can improve debugging of communications over the network. A data packet will identify from which source node to which destination node the data packet is traversing. The data packet also indicates the path instance it signifies. The path instance identifier can be especially useful if the network operator uniformly assigned instance identifiers to indicate path attributes. For example, using instance“Instancel” for higher bandwidth communication and“Instance2” for low latency communication. Additionally, the network programming action field of the destination address structure will identify what network program function is being executed on a data packet at the egress node.

[0084] FIG. 6 is a flow diagram of a method 600 of sending data using a communication network. The communication network includes a PPR domain. In some examples, the communication network implements the IPv6 protocol.

At 605, a data packet is sent from a source node using the PPR domain of the communication network. The destination address field of the data packet includes a preferred path routing identifier (PPR-ID). The PPR-ID includes a destination node identifier, a source node identifier, and a path instance identifier that identifies a specific network path for the data packet from the source node to the destination node.

[0085] This structure of the packet destination address field provides a unique PPR identifier for each PPR path between a network source node and a network destination node. The address structure provides address allocation while avoiding the need for a central controller to perform the allocation.

[0086] The identifier node space for the source nodes may be a node space parallel or disjoint to the node space of the destination node. The destination address structure may be totally decentralized if the network nodenumbers are automatically negotiated by the network nodes, but assigning the node numbers centrally may have network management advantages. Once the nodes are determined the destination addresses can be determined automatically. Because the determination of the destination addresses is structed using the PPR- ID, any node within the PPR domain of the network can generate a PPR-ID for a data packet without input from a central controller or intervention of a network operator. [0087] Once a receiver node has its own node identifier, the receiver node can advertise the identifier and any node within the PPR domain can construct a unique PPR path identifier (PPR-ID) from any source node to that receiver node without a risk of a PPR-ID clash and without a need to consult the receiving node for additional information to determine the unique PPR-ID. The instances of the generated PPR-IDs can also be determined by a source node without consulting the receiving node.

[0088] At 610, a routing prefix and a PPR suffix are included in the packet destination and the PPR-ID is included in the PPR suffix. At 615, an identifier of a network programming action is appended to the PPR suffix in the packet destination address if desired. The identifier of the network programming action identifies an action to be performed on the data packet when it is received at the destination node. This allows network programming to be performed without needing a special prefix dedicated for network programming.

[0089] Using a structured PPR suffix in a network address (e.g., an IPv6 address) as a PPR-ID simplifies the signaling requirements among the network nodes and avoids the need for signaling sessions between a source node and receiver node. The packet address structure can be flexible on a per-network basis and multiple versions of the structure can run concurrently within a PPR domain.

[0090] FIG. 7 is a block schematic diagram of a computer system 700 for performing methods and algorithms according to example embodiments. All components need not be used in various embodiments.

[0091] One example is a computing device that may include a processing unit 702, memory 703, removable storage 710, and non-removable storage 712. Although the example computing device is illustrated and described as computer 700, the computing device may be in different forms in different embodiments. For example, the computing device may be a server, a router, or a virtual router.

[0092] Although the various data storage elements are illustrated as part of the computer 700, the storage may also or alternatively include cloud-based storage accessible via a network, such as the Internet or server-based storage. Note also that an SSD may include a processor on which the parser may be run, allowing transfer of parsed, filtered data through VO channels between the SSD and main memory.

[0093] Memory 703 may include volatile memory 714 and non-volatile memory 708. Computer 700 may include— or have access to a computing environment that includes— a variety of computer-readable media, such as volatile memory 714 and non-volatile memory 708, removable storage 710 and non-removable storage 712. Computer storage includes random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD ROM), Digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.

[0094] Computer 700 may include or have access to a computing environment that includes input interface 706, output interface 704, and a communication interface 716. Output interface 704 may include a display device, such as a touchscreen, that also may serve as an input device. The input interface 706 may include one or more of a touchscreen, touchpad, mouse, keyboard, camera, one or more device-specific buttons, one or more sensors integrated within or coupled via wired or wireless data connections to the computer 700, and other input devices. The computer 700 may operate in a networked environment using a communication connection to connect to one or more remote computers, such as database servers. The remote computer may include a personal computer (PC), server, router, network PC, a peer device or other common data flow network switch, or the like. The communication connection may include a Local Area Network (LAN), a Wide Area Network (WAN), cellular, Wi-Fi, Bluetooth, or other networks. According to one embodiment, the various components of computer 700 are connected with a system bus 720.

[0095] Computer-readable instructions stored on a computer-readable medium are executable by the processing unit 702 of the computer 700, such as a program 718. The program 718 in some embodiments comprises software to implement one or more methods described herein. A hard drive, CD-ROM, and RAM are some examples of articles including a non-transitory computer- readable medium, such as a storage device. The terms computer-readable medium and storage device do not include carrier waves to the extent carrier waves are deemed too transitory. Storage can also include networked storage, such as a storage area network (SAN). Computer program 718 along with the workspace manager 722 may be used to cause processing unit 702 to perform one or more methods or algorithms described herein.

[0096] FIG. 8 is a schematic diagram of an example of a network device

800 for implementing a destination address structure based PPR-ID allocation. The network device 800 may be a device that communicates electrical and/or optical signals through a network, e.g., a switch, router, bridge, gateway, etc. In some cases, the network device 800 may act alone, or in concert with other network devices 800 to operate a virtual network device with the functionality described herein. As shown in FIG. 8, the network device 800 may comprise transceivers (Tx/Rx) 810, which may be transmitters, receivers, or combinations thereof. A Tx/Rx 810 may be coupled to a plurality of downstream

ports 820 (e.g., downstream interfaces) for transmitting and/or receiving frames from other nodes and a Tx/Rx 810 coupled to a plurality of upstream

ports 850 (e.g., upstream interfaces) for transmitting and/or receiving frames from other nodes, respectively. A processor 830 may be coupled to the

Tx/Rxs 810 to process the data signals and/or determine to which nodes to send data signals.

[0097] Processor 830 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 network device 800 may comprise a data packet encoding module 814, which may be configured to encode data packets with a PPR-ID. The data packet encoding module 814 may be implemented in a general-purpose processor, a field programmable gate array (FPGA), an ASIC, a DSP, a microcontroller, etc. In alternative embodiments, the data packet encoding module 814 may be implemented in processor 830 as computer executable instructions stored in memory device 832 (e.g., as a computer program product stored in a non-transitory computer readable medium), which may be executed by processor 830, and/or implemented in part in the processor 830 and in part in the memory device 832. The downstream ports 820 and/or upstream ports 850 may contain wireless, electrical and/or optical transmitting and/or receiving components, depending on the

embodiment.

[0098] Although a few embodiments have been described in detail above, other modifications are possible. For example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. Other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Other embodiments may be within the scope of the following claims.

Claims

CLAIMS What is claimed is:

1. A network node of a communication network, the network node comprising:

processing circuitry configured to:

encode a data packet to send via the network, wherein the data packet includes a preferred path routing identifier (PPR-ID) in a packet destination address field that identifies a path along network nodes of the communication network, wherein the PPR-ID includes:

a destination node identifier; and

a source node identifier; and

send the data packet to another network node of the communication network.

2. The network node of claim 1, wherein the PPR-ID further includes a first path instance identifier of multiple path instance identifiers that identify specific network paths for the data packet from the source node to the destination node.

3. The network node of claim 2, wherein higher order bits of the PPR-ID include the destination node identifier and lower order bits of the PPR-ID include the path instance identifier.

4. The network node of claim 1, wherein the packet destination address field includes a routing prefix and a PPR suffix, and the PPR-ID is included in the PPR suffix.

5. The network node of claim 4, wherein the processing circuitry is configured to encode the data packet to include, in the packet destination address field, an identifier of a network programming action appended to the PPR suffix that identifies an action to be performed on the data packet when it is received at the destination node.

6. The network node of claim 1 , wherein processing circuitry is configured to encode the PPR-ID using a node identifier space for the destination node identifier that is disjoint from the node identifier space for the source node identifier.

7. The network node of claim 1, wherein the processing circuitry is configured to encode the PPR-ID using an identifier of a root node of a PPR tree as the destination node identifier.

8. The network node of claim 1 , wherein the communication network is a

PPR domain of an Internet Protocol version 6 (IPv6) network.

9. The network node of any one of claims 1-8, wherein the processing circuitry is configured to:

decode a first data packet received via the network, wherein the first data packet includes a first PPR-ID;

decode a second data packet received via the network, wherein the second data packet includes a second PPR-ID; and

apply a network resource to the second data packet different from a network resource applied to the first data packet.

10. The network node of claim 1, wherein the processing circuitry is configured to generate the PPR-ID for the data packet according to a network protocol when network node numbers for the communication network are advertised.

11. The network node of claim 10, wherein the processing circuitry is configured to generate the PPR-ID for the data packet without receiving information from a central network controller.

12. The network node of claim 10 or claim 11, wherein the processing circuitry is configured to generate the PPR-ID for the data packet without receiving information from the destination node in addition to the destination node identifier.

13. A system comprising a communication network including a plurality of network nodes of the network node of any of claims 1-12, wherein a PPR-ID generated by a network node of the plurality of network nodes is guaranteed to be unique among PPR-IDs generated by the plurality of network nodes.

14. A computer implemented method of sending data using a communication network, the method comprising:

sending a data packet from a network source node via a preferred path routing (PPR) domain of the communication network; and

including a preferred path routing identifier (PPR-ID) in a packet destination address field of the data packet, wherein the PPR-ID identifies a path along network nodes of the communication network, and the PPR-ID includes a destination node identifier and a source node identifier.

15. The method of claim 14, wherein including a PPR-ID in the packet destination address field further includes including a first path instance identifier of multiple path instance identifiers in the destination address field that identify specific network paths for the data packet from the source node to the destination node.

16. The method of claim 15, wherein the sending of the data packet includes sending a data packet that includes the destination node identifier in higher order bits of the PPR-ID and includes the path instance identifier in lower order bits of the PPR-ID include.

17. The method of claim 14, wherein the sending of the data packet includes: sending a data packet that includes a routing prefix and a PPR suffix in the packet destination address field; and

including the PPR-ID in the PPR suffix.

18. The method of claim 17, wherein the sending of the data packet includes sending a data packet that includes an identifier of a network programming action appended to the PPR suffix in the packet destination address field, wherein the identifier of the network programming action identifies an action to be performed on the data packet when it is received at the destination node.

19. The method of claim 14, including selecting an identifier value for the destination node identifier from a first node identifier space that is disjoint from a second node identifier space used to select an identifier value for the source node identifier.

20. The method of claim 14, wherein the sending of the data packet includes sending a data packet that includes an identifier of a root node of a PPR tree as the destination node identifier.

21. The method of claim 14, wherein sending the data packet includes sending a data packet that includes a path instance identifier unique to a destination node identifier and source node identifier pair, and not unique to the communication network.

22. The method of claim 14, wherein the sending of the data packet includes: routing a first data packet using a first PPR-ID that includes a first destination node identifier, a first source node identifier, and a first path instance identifier;

routing a second data packet using a second PPR-ID that includes the first destination node identifier, the first source node identifier, and a second path instance identifier; and

applying a network resource to the second data packet different from a network resource applied to the first data packet.

23. The method of claim 14, wherein the including of the PPR-ID in the packet destination address field further includes including a path instance identifier in the destination address field that identifies a multi-point to point network path for the data packet.

24. The method of any one of claims 14-23, wherein the including of the

PPR-ID in the packet destination address field further includes including a path instance identifier in the destination address field that identifies a multi-point to multi-point network path for the data packet.

25. The method of claim 14, including generating the PPR-ID for the data packet according to a network protocol when network node numbers for the communication network are advertised.

26. The method of claim 25, including generating the PPR-ID for the data packet without receiving information from a central network controller.

27. The method of claim 25, including generating the PPR-ID for the data packet without receiving information from the destination node in addition to the destination node identifier.

28. A computer-readable storage medium, storing instructions for execution by a processing circuitry of a computing device to cause the processing circuitry to perform operations comprising:

encoding a data packet to send via a communication network, wherein the data packet includes a preferred path routing identifier (PPR-ID) in a packet destination address field, wherein the PPR-ID includes:

a destination node identifier;

a source node identifier; and

a first path instance identifier of multiple path instance identifiers that identify specific network paths for the data packet from the source node to the destination node.

29. The computer-readable storage medium of claim 28, including instructions to cause the processing circuitry to include a routing prefix and a PPR suffix in the packet destination address field, and include the PPR-ID in the PPR suffix.

30. The computer-readable storage medium of claim 29, including instructions to cause the processing circuitry to encode the data packet to include, in the packet destination address field, an identifier of a network programming action appended to the PPR suffix, wherein the identifier of the network programming action identifies an action to be performed on the data packet when it is received at the destination node.

31. The computer-readable storage medium of any one of claims 28-30, including instructions to cause the processing circuitry to encode the data packet to include an identifier of a root node of a PPR tree as the destination node identifier.

32. A network node of a communication network, the network node comprising:

processing circuitry configured to:

receive network node identifier information;

encode a transmit data packet according to a network protocol, wherein the encoded transmit data packet includes a preferred path routing identifier (PPR-ID) that identifies a path of network nodes of the communication network; and

send the encoded transmit data packet to another network node of the communication network.

33. The network node of claim 32, wherein the processing circuitry is configured to generate the PPR-ID to include a destination node identifier and a source node identifier without information from a central controller of the communication network.

34. The network node of claim 32 or 33, wherein the processing circuitry is configured to generate the PPR-ID to further include a first path instance identifier of multiple path instance identifiers that identify specific network paths for the transmit data packet from the source node to the destination node.

35. A computer implemented method of sending data using a communication network, the method comprising:

receiving network node identifier information at a network node of the communication network;

encoding a transmit data packet according to a network protocol, wherein the encoded transmit data packet includes a preferred path routing identifier (PPR-ID) that identifies a path of network nodes of the communication network; and

sending the encoded transmit data packet to another network node of the communication network.

36. The method of claim 35, including generating the PPR-ID to include a destination node identifier and a source node identifier without information from a central controller of the communication network.

37. The method of claim 35 or 36, including generating the PPR-ID to further include a first path instance identifier of multiple path instance identifiers that identify specific network paths for the transmit data packet from the source node to the destination node.