WO2020247742A1

WO2020247742A1 - Network connectivity verification and negotiation

Info

Publication number: WO2020247742A1
Application number: PCT/US2020/036311
Authority: WO
Inventors: Padmadevi Pillay-Esnault; Alvaro Retana
Original assignee: Futurewei Technologies, Inc.
Priority date: 2019-06-07
Filing date: 2020-06-05
Publication date: 2020-12-10

Abstract

A method performed by a network element (NE) in a network, comprising maintaining a database indicating a topology of the network, receiving an advertisement from a neighboring NE, wherein the advertisement comprises a source NE identifier (ID) identifying a source NE from which the advertisement originated, and determining whether the advertisement is valid based on a portion of a path along which the advertisement is received, the source NE ID, and the topology of the network.

Description

Network Connectivity Verification and Negotiation

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of U.S. Provisional Patent Application No.

62/858,726 filed June 7, 2019 by Padmadevi Pillay-Esnault, et al, and entitled“Remote Neighbor

Connectivity Check in Service Groupings,” U.S. Provisional Patent Application No. 62/860,453 filed June 12, 2019 by Padmadevi Pillay-Esnault, et al, and entitled “Flooding Algorithm

Discovery and Local Processing Options in Service Groupings,” and “U.S. Provisional Patent

Application No. 62/863,645 filed June 19, 2019 by Padmadevi Pillay-Esnault, et al, and entitled

“Flooding Algorithm Negotiation in Service Groupings,” each of which is hereby incorporated by reference.

FIELD OF INVENTION

[0002] The present disclosure pertains to the field of data transmission in a network implementing an Interior Gateway Protocol (IGP), such as Open Shortest Path First (OSPF) version 2 (OSPFv2) or OSPF version 3 (OSPFv3). In particular, the present disclosure relates to the secure flooding of data through the network implementing an IGP.

BACKGROUND

[0003] An IGP is a type of protocol used for exchanging information among network elements (NEs), such as routers, switches, gateways, etc., within a network (also referred to herein as an“autonomous system (AS)” or a“domain”). The information exchanged using IGP may include routing information and/or state information. The information can be used to route data using network-layer protocols, such as Internet Protocol (IP). [0004] IGPs can be divided into two categories: distance-vector routing protocols and link- state routing protocols. In a network implementing a distance-vector routing protocol, each NE in the network does not possess information about the full network topology. Instead, each NE advertises a distance value calculated to other routers and receives similar advertisements from other routers. Each NE in the network uses the advertisements to populate a local routing table.

[0005] In contrast, in a network implementing a link- state routing protocol, each NE stores network topology information about the complete network topology. Each NE then independently calculates the next best hop from the NE for every possible destination in the network using the network topology information. The NE then stores a routing table including the collection of next best hops to every possible destination. Each NE in the network forwards the information encoded according to an IGP to adjacent NEs, thereby flooding the network with the information that is saved at each of the NEs in the network. Examples of link-state routing protocols include Intermediate System to Intermediate System (IS-IS), OSPFv2, and OSPFv3.

[0006] OSPFv2 and OSPFv3 are dynamic routing protocols that quickly detect topological changes and calculate new loop free routes after a period of convergence. Each NE in the network implementing an OSPF protocol includes a link-state database (LSDB) and a routing table. The LSDB describes a topology of the network, and each NE in the network maintains an identical LSDB. Each entry in the LSDB describes a particular NE’s local state (e.g., usable interfaces and reachable neighbors). Each NE constructs a tree of shortest paths with the respective NE as the root using the LSDB. This shortest path tree indicates the route from the respective NE to each destination in the network and is used to construct the routing table maintained by the respective NE. SUMMARY

[0007] According to a first aspect of the present disclosure, there is provided a method performed by an NE in a network, comprising maintaining a database indicating a topology of the network, receiving an advertisement from a neighboring NE, wherein the advertisement comprises a source NE identifier (ID) identifying a source NE from which the advertisement originated, and determining whether the advertisement is valid based on a portion of a path along which the advertisement is recei ved, the source NE ID, and the topology of the network.

[0008] Optionally, in a first implementation according to the first aspect, the neighboring NE and the NE are both members of a service group, and wherein the determining whether the advertisement is valid is also based on the NEs in the service group.

[0009] Optionally, in a second implementation according to the first aspect or any other implementation of the first aspect, the determining whether the advertisement is valid comprises determining that the advertisement is valid, and wherein the method further comprises forwarding the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

[0010] Optionally, in a third implementation according to the first aspect or any other implementation of the first aspect, the neighboring NE and the NE are not members of a common service group.

[0011] Optionally, in a fourth implementation according to the first aspect or any other implementation of the first aspect, determining whether the advertisement is valid comprises determining that the advertisement is invalid, and wherein the advertisement is not flooded to another neighbor of the NE in response to determining that the advertisement is invalid. [0012] Optionally, in a fifth implementation according to the first aspect or any other implementation of the first aspect, determining whether the advertisement is valid comprises determining that the portion of the path along which the advertisement is received is on a path from the source NE to the NE based on the topology of the network, and determining that the advertisement is valid, and wherein the method further comprises forwarding the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

[0013] Optionally, in a sixth implementation according to the first aspect or any other implementation of the first aspect, wherein determining whether the advertisement is valid comprises determining that the portion of the path along which the advertisement is received is not on a path from the source NE to the NE based on the topology of the network, and determining that the advertisement is invalid, wherein the advertisement is not flooded to another neighbor of the

NE in response to the determining that the advertisement is invalid.

[0014] Optionally, in a seventh implementation according to the first aspect or any other implementation of the first aspect, the method further comprises transmitting a first advertisement including verification criteria to all neighboring NEs before receiving the advertisement from the neighboring NE, wherein the verification criteria indicates a path type used by the NE to verify a second advertisement, wherein determining whether the advertisement is valid comprises determining whether the advertisement is valid based on the verification criteria, the portion of the path along which the second advertisement is received, the source NE ID, and the topology of the network.

[0015] Optionally, in an eighth implementation according to the first aspect or any other implementation of the first aspect, the path type indicated by the verification criteria includes at least one of a strict path, a shortest path, a matching best path, a backup path, a preferred path route

(PPR), and a traffic-engineered (TE) path.

[0016] Optionally, in a ninth implementation according to the first aspect or any other implementation of the first aspect, wherein determining whether the advertisement is valid comprises determining a path between the source NE and the NE based on the path type indicated by the verification criteria, and determining whether the portion of the path along which the advertisement is received is on the path between the source NE and the NE, wherein the portion of the path along which the advertisement is received includes the neighboring NE.

[0017] Optionally, in a tenth implementation according to the first aspect or any other implementation of the first aspect, determining whether the advertisement is valid comprises determining that the advertisement is invalid in response to determining that portion of the path along which the second advertisement is received is not on the path between the source NE and the

NE, wherein the advertisement is not flooded to another neighboring NE in response to determining that the advertisement is invalid.

[0018] Optionally, in a eleventh implementation according to the first aspect or any other implementation of the first aspect, determining whether the advertisement is valid comprises determining that the advertisement is valid in response to determining that the portion of the path along which the second advertisement is received is on the path between the source NE and the

NE, and wherein the method further comprises forwarding the second advertisement to the next neighboring NE response to determining that the advertisement is valid.

[0019] Optionally, in a twelfth implementation according to the first aspect or any other implementation of the first aspect, the first advertisement comprises the verification criteria and a negotiation policy, wherein the verification criteria indicates a first set of path types used to verify the advertisement received by the NE, wherein the first set of path types includes one or more path types, and wherein the negotiation policy indicates a manner by which to select a single path type for use by a plurality of NEs including the NE in verifying the second advertisement.

[0020] Optionally, in a thirteenth implementation according to the first aspect or any other implementation of the first aspect, the method further comprises receiving another first advertisement from a second NE, wherein the other first advertisement indicates the negotiation policy and a second set of path types used to verify subsequent advertisements received by the second NE, wherein the second set of path types includes one or more path types, and determining the single path type from the first set of path types and the second set of path types based on the negotiation policy.

[0021] Optionally, in a fourteenth implementation according to the first aspect or any other implementation of the first aspect, the negotiation policy indicates that a plurality of NEs including the NE use a path type that is indicated in both the first set of path types and the second set of path types as the single path type.

[0022] Optionally, in a fifteenth implementation according to the first aspect or any other implementation of the first aspect, the negotiation policy indicates that a plurality of NEs including the NE use a default path type as the single path type.

[0023] Optionally, in a sixteenth implementation according to the first aspect or any other implementation of the first aspect, the negotiation policy indicates that a plurality of NEs including the NE use a path type defined by a central entity of the network as the single path type.

[0024] Optionally, in a seventeenth implementation according to the first aspect or any other implementation of the first aspect, the first set of path types and the second set of path types do not include a matching path type, and wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type defined by a central entity of the network as the single path type.

[0025] Optionally, in a eighteenth implementation according to the first aspect or any other implementation of the first aspect, the first set of path types and the second set of path types include at least two matching path types, and wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type or a path type defined by a central entity of the network as the single path type.

[0026] Optionally, in a nineteenth implementation according to the first aspect or any other implementation of the first aspect, the first set of path types and the second set of path types include at least two matching path types, and wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type having a maximum or minimum encoding value as the single path type.

[0027] Optionally, in a twentieth implementation according to the first aspect or any other implementation of the first aspect, the portion of the path along which the advertisement is received comprises a last portion of the path along which the advertisement is received.

[0028] Optionally, in a twenty first implementation according to the first aspect or any other implementation of the first aspect, the last portion of the path along which the advertisement is received comprises the neighboring NE.

[0029] According to a second aspect of the present disclosure, there is provided a network element (NE) comprising a memory storing instructions, and a processor coupled to the memory and configured to execute the instructions, which cause the processor to be configured to maintain a database indicating a topology of the network, receive an advertisement from a neighboring NE, wherein the advertisement comprises a source NE identifier (ID) identifying a source NE from which the advertisement originated, and determine whether the advertisement is valid based on a portion of a path along which the advertisement is received, the source NE ID, and the topology of the network.

[0030] Optionally, in a first implementation according to the second aspect, the neighboring

NE and the NE are both members of a service group, and wherein a determination of whether the advertisement is valid is also based on the NEs in the service group.

[0031] Optionally, in a second implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to determine that the advertisement is valid, and forward the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

[0032] Optionally, in a third implementation according to the second aspect or any other implementation of the second aspect, the neighboring NE and the NE are not members of a common service group, and wherein the instructions further cause the processor to be configured to determine that the advertisement is invalid, and wherein the advertisement is not flooded to another neighbor of the NE in response to determining that the advertisement is invalid.

[0033] Optionally, in a fourth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to determine that the portion of the path along which the advertisement is received is on a path from the source NE to the NE based on the topology of the network, determine that the advertisement is valid, and forward the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

[0034] Optionally, in a fifth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to determine that the portion of the path along which the advertisement is received is not on a path from the source NE to the NE based on the topology of the network, and determine that the advertisement is invalid, wherein the advertisement is not flooded to another neighbor of the NE in response to the determining that the advertisement is invalid.

[0035] Optionally, in a sixth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to transmit a first advertisement including verification criteria to all neighboring NEs before receiving the advertisement from the neighboring NE, wherein the verification criteria indicates a path type used by the NE to verify a second advertisement, and determine whether the advertisement is valid based on the verification criteria, the portion of the path along which the second advertisement is received, the source NE ID, and the topology of the network.

[0036] Optionally, in a seventh implementation according to the second aspect or any other implementation of the second aspect, the path type indicated by the verification criteria includes at least one of a strict path, a shortest path, a matching best path, a backup path, a preferred path route

(PPR), and a traffic-engineered (TE) path.

[0037] Optionally, in an eighth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to determine a path between the source NE and the NE based on the path type indicated by the verification criteria, and determine whether the portion of the path along which the advertisement is received is on the path between the source NE and the NE, wherein the portion of the path along which the advertisement is received includes the neighboring NE.

[0038] Optionally, in a ninth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to determine that the advertisement is invalid in response to determining that portion of the path along which the second advertisement is received is not on the path between the source NE and the

[0039] Optionally, in a tenth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to determine that the advertisement is valid in response to determining that the portion of the path along which the second advertisement is received is on the path between the source NE and the

[0040] Optionally, in a eleventh implementation according to the second aspect or any other implementation of the second aspect, the first advertisement comprises the verification criteria and a negotiation policy, wherein the verification criteria indicates a first set of path types used to verify the advertisement received by the NE, wherein the first set of path types includes one or more path types, and wherein the negotiation policy indicates a manner by which to select a single path type for use by a plurality of NEs including the NE in verifying the second advertisement.

[0041] Optionally, in a twelfth implementation according to the second aspect or any other implementation of the second aspect, the instructions further cause the processor to be configured to receive another first advertisement from a second NE, wherein the other first advertisement indicates the negotiation policy and a second set of path types used to verify subsequent advertisements received by the second NE, wherein the second set of path types includes one or more path types, and determine the single path type from the first set of path types and the second set of path types based on the negotiation policy. [0042] Optionally, in a thirteenth implementation according to the second aspect or any other implementation of the second aspect, the negotiation policy indicates that a plurality of NEs including the NE use a path type that is indicated in both the first set of path types and the second set of path types as the single path type.

[0043] Optionally, in a fourteenth implementation according to the second aspect or any other implementation of the second aspect, the negotiation policy indicates that a plurality of NEs including the NE use a default path type as the single path type.

[0044] Optionally, in a fifteenth implementation according to the second aspect or any other implementation of the second aspect, the negotiation policy indicates that a plurality of NEs including the NE use a path type defined by a central entity of the network as the single path type.

[0045] Optionally, in a sixteenth implementation according to the second aspect or any other implementation of the second aspect, the portion of the path along which the advertisement is received comprises a last portion of the path along which the advertisement is received, and wherein the last portion of the path along which the advertisement is received comprises the neighboring NE.

[0046] According to a third aspect of the present disclosure, there is provided a non-transitory computer-readable medium configured to store a computer program product comprising computer executable instructions that, when executed by a processor of a NE implemented in a network, cause the processor to be configured to maintain a database indicating a topology of the network, receive an advertisement from a neighboring NE, wherein the advertisement comprises a source

NE identifier (ID) identifying a source NE from which the advertisement originated, and determine whether the advertisement is valid based on a portion of a path along which the advertisement is received, the source NE ID, and the topology of the network. [0047] Optionally, in a first implementation according to the third aspect, the neighboring NE and the NE are both members of a service group, and wherein a determination of whether the advertisement is valid is also based on the NEs in the service group.

[0048] Optionally, in a second implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to determine that the advertisement is valid, and forward the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

[0049] Optionally, in a third implementation according to the third aspect or any other implementation of the third aspect, the neighboring NE and the NE are not members of a common service group, and wherein the computer executable instructions further cause the processor to be configured to determine that the advertisement is invalid, and wherein the advertisement is not flooded to another neighbor of the NE in response to determining that the advertisement is invalid.

[0050] Optionally, in a fourth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to determine that the portion of the path along which the advertisement is received is on a path from the source NE to the NE based on the topology of the network, determine that the advertisement is valid, and forward the advertisement to the next neighboring

NE in response to determining that the advertisement is valid.

[0051] Optionally, in a fifth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to determine that the portion of the path along which the advertisement is received is not on a path from the source NE to the NE based on the topology of the network. and determine that the advertisement is invalid, wherein the advertisement is not flooded to another neighbor of the NE in response to the determining that the advertisement is invalid.

[0052] Optionally, in a sixth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to transmit a first advertisement including verification criteria to all neighboring NEs before receiving the advertisement from the neighboring NE, wherein the verification criteria indicates a path type used by the NE to verify a second advertisement, and determine whether the advertisement is valid based on the verification criteria, the portion of the path along which the second advertisement is received, the source NE ID, and the topology of the network.

[0053] Optionally, in a seventh implementation according to the third aspect or any other implementation of the third aspect, the path type indicated by the verification criteria includes at least one of a strict path, a shortest path, a matching best path, a backup path, a preferred path route

(PPR), and a traffic-engineered (IE) path.

[0054] Optionally, in an eighth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to determine a path between the source NE and the NE based on the path type indicated by the verification criteria, and determine whether the portion of the path along which the advertisement is received is on the path between the source NE and the NE, wherein the portion of the path along which the advertisement is received includes the neighboring NE.

[0055] Optionally, in a ninth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to determine that the advertisement is invalid in response to determining that portion of the path along which the second advertisement is received is not on the path between the source NE and the NE, wherein the advertisement is not flooded to another neighboring NE in response to determining that the advertisement is invalid.

[0056] Optionally, in a tenth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to determine that the advertisement is valid in response to determining that the portion of the path along which the second advertisement is received is on the path between the source NE and the NE, and wherein the method further comprises forwarding the second advertisement to the next neighboring NE response to determining that the advertisement is valid.

[0057] Optionally, in a eleventh implementation according to the third aspect or any other implementation of the third aspect, the first advertisement comprises the verification criteria and a negotiation policy, wherein the verification criteria indicates a first set of path types used to verify the advertisement received by the NE, wherein the first set of path types includes one or more path types, and wherein the negotiation policy indicates a manner by which to select a single path type for use by a plurality of NEs including the NE in verifying the second advertisement.

[0058] Optionally, in a twelfth implementation according to the third aspect or any other implementation of the third aspect, the computer executable instructions further cause the processor to be configured to receive another first advertisement from a second NE, wherein the other first advertisement indicates the negotiation policy and a second set of path types used to verify subsequent advertisements received by the second NE, wherein the second set of path types includes one or more path types, and determine the single path type from the first set of path types and the second set of path types based on the negotiation policy. [0059] Optionally, in a thirteenth implementation according to the third aspect or any other implementation of the third aspect, the negotiation policy indicates that a plurality of NEs including the NE use a path type that is indicated in both the first set of path types and the second set of path types as the single path type.

[0060] Optionally, in a fourteenth implementation according to the third aspect or any other implementation of the third aspect, the negotiation policy indicates that a plurality of NEs including the NE use a default path type as the single path type.

[0061] Optionally, in a fifteenth implementation according to the third aspect or any other implementation of the third aspect, the negotiation policy indicates that a plurality of NEs including the NE use a path type defined by a central entity of the network as the single path type.

[0062] Optionally, in a sixteenth implementation according to the third aspect or any other implementation of the third aspect, the portion of the path along which the advertisement is received comprises a last portion of the path along which the advertisement is received, and wherein the last portion of the path along which the advertisement is received comprises the neighboring NE.

[0063] For the purpose of clarity, any one of the foregoing embodiments may be combined with any one or more of the other foregoing embodiments to create a new embodiment within the scope of the present disclosure.

[0064] These and other features will be more clearly understood from the following detailed description taken in conjunction with the accompanying drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0065] For a more complete understanding of this disclosure, reference is now made to the following brief description, taken in connection with the accompanying drawings and detailed description, wherein like reference numerals represent like parts.

[0066] FIG. I A is a schematic diagram illustrating a network configured to implement net work connectivity verification according to various embodiments of the disclosure.

[0067] FIG. 1 B is another schematic diagram illustrating a network configured to implement network connectivity verification according to various embodiments of the disclosure.

[0068] FIG. 1C is another schematic diagram illustrating a network configured to implement network connectivity verification according to various embodiments of the disclosure.

[0069] FIG. 2 is a schematic diagram of an NE suitable to implement network connectivity verification according to various embodiments of the disclosure.

[0070] FIG. 3 is a schematic diagram of another network configured to implement network connectivity verification according to various embodiments of the disclosure.

[0071] FIG. 4 is a schematic diagram illustrating the network of FIG. 3, which is further configured to advertise verification criteria to implement network connectivity verification according to various embodiments of the disclosure.

[0072] FIGS. 5A-B are schematic diagrams illustrating examples of the first advertisement that is flooded through the network of FIG. 4 according to a first embodiment of the disclosure.

[0073] FIG. 6 is a schematic diagram illustrating the network of FIG. 3, which is further configured to advertise a negotiation policy to implement network connectivity verification according to various embodiments of the disclosure. [0074] FIGS. 7A-B are schematic diagrams illustrating examples of the first advertisement that is flooded through the network of FIG. 6 according to a first embodiment of the disclosure.

[0075] FIG. 8 is a flowchart illustrating a method for implementing network connectivity verification according to various embodiments of the disclosure.

[0076] FIG. 9 is a flowchart illustrating a method for implementing network connectivity verification according to various embodiments of the disclosure.

[0077] FIG. 10 is a schematic diagram illustrating an apparatus to implement network connectivity verification according to various embodiments of the disclosure.

[0078] FIG. 11 is a schematic diagram illustrating an apparatus to implement network connectivity verification according to various embodiments of the disclosure.

DETAILED DESCRIPTION

[0079] It should be understood at the outset that although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure should in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

[0080] FIG. 1A is a schematic diagram illustrating a network 100 (also referred to herein as an

“autonomous system (AS)” or “domain”) configured to implement network connectivity verification according to various embodiments of the disclosure. In an embodiment, network 100 is configured to implement an OSPF protocol. As used herein, the term“OSPF protocol” (also referred to herein as“OSPF”) may refer to a routing protocol, such as, for example, OSPFv2,

OSPFv3, or any other IGP that implements a flooding mechanism similar to OSPFv2 or OSPFv3.

Network TOO comprises a central entity 103 (also referred to herein as a“controller”) and multiple

NEs 104-114. In the embodiment shown in FIG. lA, the central entity 103 is coupled to NE 109 in the network 100 via the central entity-to-NE link 125. While FIG. 1 A shows that the central entity

103 is only coupled to a single NE 109 in the network 100, in other embodiments, the central entity

103 may be directly coupled to one or more NEs 104-114 in the network 100. Within network

100, the NEs 104-114 are interconnected by links 123.

[0081] In an embodiment, the central entity 103 may be substantially similar to a Path

Computation Element (PCE), which is further described in Internet Engineering Task Force (IETF)

Request for Comments (RFC) 8281, entitled“Path Computation Element Communication Protocol

(PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model,” by E. Crabbe, dated

December 2017, which is incorporated by reference herein in its entirety. In an embodiment, the central entity 103 may be substantially similar to a Software Defined Network Controller (SDNC), which is further described in the IETF RFC 8402 entitled“Segment Routing Architecture,” by C.

Filsfils, dated July 2018, which is incorporated by reference herein in its entirety. In an embodiment, the central entity 103 may be substantially similar to an Application Layer Traffic

Optimization (ALTO) server, which is further described in the IETF RFC 7285, entitled

“Application Layer Traffic Optimization (ALTO) Protocol,” by R. Alimi, dated September 2014, which is incorporated by reference herein in its entirety.

[0082] NEs 104-114 may each be a physical device, such as a router, a bridge, a network switch, or a logical device, such as a virtual machine, configured to forward data across the network 100 by encoding the data according to an OSPF protocol. In an embodiment, at least some of the NEs 104-114 are headend nodes or edge nodes positioned at an edge of the network

100. For example, one or more of NEs 104-114 may be an ingress node at which traffic (e.g., control packets and data packets) is received, and one or more of NEs 104-114 may be an egress node from which traffic is transmitted. Some of the NEs 104-114, such as NEs 108 and 107, may be interior nodes that are configured to receive and forward traffic from another NE 104-114 in the network 100.

[0083] The central entity-to-NE link 125 may be wired links, wireless links, or interfaces interconnecting at least one NE 109 with the central entity 103. Similarly, the links 123 may be wired links, wireless links, or interfaces interconnecting each of the NEs 104-114.

[0084] Although only eleven NEs 104-114 are shown in FIG. 1A, it should be appreciated that the network 100 shown in FIG. 1A may include any number of NEs, such as at least eleven, more than eleven, or more than 100. In an embodiment, the central entity 103 and NEs 104-114 are configured to implement various packet forwarding protocols, such as, but not limited to, Multi- protocol Label Switching (MPLS), IP version 4 (IPv4), IP version 6 (IPv6), and Big Packet

Protocol.

[0085] Each of the NEs 104-114 may receive an advertisement including information related to the network 100 using an OSPF protocol. The information may be received from the central entity 103, another NE 104-114 in the network 100, another NE or entity external to the network

100, or an operator of the network 100. An NE 104-114 may also generate an advertisement including information related to the NE 104-114 in the network 100.

[0086] The advertisements may be link state advertisements (LSAs) pursuant to the OSPF protocol, and the LSAs may each carry link state information, routing information, security information, or any other information relevant to the NEs 104-114. Additional details regarding contents of the LSA is described in Network Working Group RFC 2328, entitled“OSPF Version

2,” dated April 1998, by J. Moy, and Network Working Group RFC 5340, entitled“OSPF for

IPv6,” dated July 2008, by R. Colton, et al, which are both incorporated by reference herein in their entireties.

[0087] The link-state information describes a state of a respective NE’s interfaces and adjacencies, such as, for example, prefixes, security identifiers (SIDs), traffic engineering (TE) information, identifiers (IDs) of adjacent NEs, links, interfaces, ports, and routes. In addition, the link-state information may include, for example, local/remote IP address, local/remote interface identifiers, link metrics and TE metrics, link bandwidth, reserveable bandwidth, per Class-of-

Service (CoS) class reservation state, preemption, and Shared Risk Link Groups (SLRGs), which is incorporated by reference herein in its entirety. The link-state information received in an advertisement may be stored in the LSDB of each NE 104-114. Each NE 104-114 may use the information stored in the LSDB to determine or obtain a topology of the network 100.

[0088] The routing information may include information describing one or more elements on a path between a source (first NE) and a destination (second NE) in the network 100. For example, the routing information may include an ID of a path and a label, address, or ID of one or more elements (e.g., NEs 104-114 or links 123) on the path. As used herein, the term“path” may refer to the shortest path, preferred path routing (PPR), or PPR graphs.

[0089] A PPR (also referred to herein as a“Non-Shortest Path (NSP)”) refers to a custom path or any other path that may deviate from the shortest path computed between two NEs 104-114 or between a source and destination. The PPRs are determined based on an application or server request for a path between two NEs 104-114 or between a source and destination that satisfies one or more network characteristics (such as TE) or service requirements. PPRs are further defined in International Patent Publication No. WO/2019/164637, filed on January 28, 2019, which is incorporated by reference herein in its entirety.

[0090] A PPR graph refers to a collection of multiple PPRs between one or more ingress NEs

104-114 (also referred to herein as“sources”) and one or more egress NEs 104-114 (also referred to herein as“destinations”). A PPR graph may include a single source and multiple destinations, multiple destinations and a single source, or multiple sources and multiple destinations. PPR graphs are further defined in International Patent Publication No. WO/2019/236221, filed on May

2, 2019, which is incorporated by reference herein in its entirety.

[0091] The routing information includes information describing each of these types of paths that have been provisioned in the network 100. The routing information received in an advertisement may be stored in the routing table of each NE 104-1 14. Each NE 104-1 14 uses the routing table to determine next hops by which to forward advertisements or other types of OSPF packets.

[0092] In some cases, the advertisements may also contain any information related to a service or application that uses one or more NEs 104-114 in the network 100. For example, the advertisements may include traffic engineering (TE) information, security information, authentication information, identification information, operations, administration, and maintenance

(OAM) information, etc. for a relevant service or application. The TE information is further described in IETF RFC 7471, entitled“OSPF Traffic Engineering (TE) Metric Extensions,” by S.

Giacalone, et al., dated March 2015, which is incorporated by reference herein in its entirety.

[0093] Whether an NE 104-114 receives an advertisement or generates an advertisement, NE

104-114 is configured to initiate OSPF flooding of the advertisement through the network 100.

During OSPF flooding, each NE 104-1 14 is configured to flood (e.g., transmit or forward) the advertisement including the information to all neighboring NEs 104-114 in the network 100. As used herein, neighboring NEs 104-114 refers to two adjacent NEs each having interfaces that can directly communicate with one another. For example, when NE 105 receives an advertisement,

NE 105 floods the advertisement to neighboring NEs 104 and 106. Each of the receiving NEs 104 and 106 then floods the advertisement to neighboring NEs 107, 109, 112, and 113. That is, NE

104 forwards the advertisement to NE 109, and NE 106 forwards the advertisement to NEs 107,

112, and 113. NEs 109, 107, 112, and 1 13 similarly update their local databases and flood the advertisement to neighboring NEs 110, 109, 111, and 114.

[0094] Each of the NEs 104-114 floods the advertisement in a single direction, and does not forward the advertisement backwards to an NE 104-1 14 from which the advertisement may have been received. For example, NE 104 receives the advertisement from NE 105 and forwards the advertisement to NE 109, but does not forward the advertisement back to NE 105, from which the advertisement was received.

[0095] In some cases, the information that is flooded through the network 100 is completely irrelevant to some of the NEs 104-114 that receive the information. In these cases, each of the NEs

104-114 nevertheless process and store this information even though the NEs 104-114 may never use the information. Further, the overall amount of information that needs to be flooded through a network 100 is continuously growing, which results in an inefficient use of the resources within a network 100. For this reason, network characteristics, such as bandwidth, throughput, latency, error rate, etc., can be significantly affected when data is unnecessarily flooded through the network 100.

[0096] To reduce the amount of information flooded through the network 100 implementing an OSPF protocol, service groups 130 can be provisioned through the network 100. A service group 130 includes one or more NEs 104-114 in a network 100, or area, that is associated with an application or a service. An NE 104-1 14 may belong to zero, one, or more service groups 130. In some cases, multiple service groups can be grouped together in a service group set.

[0097] As shown in FIG. 1A, the service group 130 includes NEs 109, 108, 107, 106, 110,

111, and 112. Service group 130 may be associated with a first service. For example, the first service may be a security service, and the second service may be an operations, administration, maintenance (OAM) service. A service group ID 140 is an identifier that identifies the service group 130. When the service group 130 is included in a service group set, then the service group set is identified by a service group set ID 145.

[0098] To provision the service group 130 in the control plane, service group capability information indicating whether an NE 104-1 14 is part of a service group 130 is flooded to all the

NEs 104-114 in the network 100 using a first advertisement 127. This way, all the NEs 104-114 in the network 100 maintain a synchronized view of the service groups 130 that are provisioned in the network 100. Then, in the flooding plane, subsequent advertisements received after flooding the first advertisement 127 (e.g., a second advertisement 137) are examined to determine whether a service group ID 140 is included in the second advertisement 137. If so, the second advertisement

137 is only forwarded to neighboring NEs 104-114 that are members of the service group 130 identified by the service group ID 140. Additional details regarding the creation and implementation of service groups 130 are described in International Application No.

PCT/US2020/031878, filed on May 7, 2020, which is incorporated by reference herein in its entirety.

[0099] In the embodiment shown in FIG. 1A, the service group 130, including NEs 109, 108,

107, 106, 110, 111, and 112, is associated with two PPRs, which may, for example, be associated with a similar service or application. In some cases, the central entity 103 determines the two

PPRs and the service group 130 based on the service or application, user requests, and or network characteristics. The central entity 103 also groups together the two PPRs into the single service group 130 based on the similar service or application.

[00100] A first PPR in the service group 130, indicated with squares in FIG. 1 A, is a path along

NE 109, 108, 107, and 106. The first PPR may be associated with a PPR-ID 142 A, which identifies the first PPR. The second PPR in the service group 130, indicated with diamonds in

FIG. 1A, is a path along NE 109, 110, 111, and 106. The second PPR may be associated with a

PPR-ID 142B, which identifies the second PPR.

[00101] As such, the first PPR and the second PPR include NEs 109, 108, 107, 106, 110, and

1 1 1. In some cases, the central entity 103 determines the NEs in the service group 130 based on the first PPR and the second PPR, but may also add NEs to the service group 130 to ensure that the

NEs in the service group 130 are topologically continuous. As used herein, the term topologically continuous refers to a condition in which NEs are directly interconnected based on the topology of the network 100.

[00102] For example, the central entity 103 may add NE 112 to the service group 130 to ensure that all the NEs 109, 108, 107, 106 110, 111, and 112 in the service group 130 are topologically continuous. In this way, information may be efficiently flooded across the NEs 109, 108, 107, 106

1 10, 111, and 1 12 in the service group 130.

[00103] After creating the service group 130, the central entity 103 sends a first advertisement

127 to at least one of the NEs 109 in the network 100 via the central entity-to-NE link 125. The first advertisement 127 includes the service group ID 140 identifying the service group 130, and the NE IDs 147 identifying each of the NEs 109, 108, 107, 106 1 10, 1 1 1, and 112 in the service group 130. In an embodiment, the first advertisement 127 includes the PPR-ID 142 A identifying the first PPR, and PPR-path description elements (PDEs) 143 A indicating the NE IDs 147 identifying each of the NEs 109, 108, 107, and 106 in the first PPR. In this embodiment, the first advertisement 127 also includes the PPR-ID 142B identifying the second PPR and PPR-PDEs

143B indicating the NE IDs 147 identifying each of the NEs 109, 110, 111, and 106 in the second

PPR. Each of the NE IDs 147 may carry a label, address, or ID uniquely identifying a respective

NE. In an embodiment in which the service group 130 is also included in a service group set, the first advertisement 127 also includes a service group set ID 145 identifying the service group set.

[00104] In the embodiment shown in FIG. lA, when NE 109 receives the first advertisement

127 from the central entity 103, NE 109 initiates standard OSPF flooding of the first advertisement

127. The flooding of the first advertisement 127 to all NEs 104-114 in the network 100 ensures that all the NEs 104-114 in the network 100 maintain a consistent database with information regarding the service groups 130 that are provisioned through the network 100. NE 109 floods the first advertisement 127 to all neighboring NEs 104, 108, and 110. NEs 104, 108, and 110 update their local databases to include the information from the first advertisement 127, and then forward the first advertisement 127 to all neighboring NEs, until every NE 104-114 stores the information from the first advertisement 127.

[00105] In other embodiments, each of NEs 104-114 may obtain the first advertisement 127 in other manners. For example, in an embodiment in which the central entity 103 is directly connected to each of NEs 104-114, the central entity 103 sends a relevant first advertisement 127 directly to all of the NEs 104-114 in the network 100. Subsequently, the NEs 104-114 may flood the network 100 with the information received from the central entity 103, to ensure that all NEs

104-114 maintain a consistent view of the service groups 130 provisioned in the network 100. In another embodiment, an operator of the network 100 may directly configure each of NEs 104-114 with the information from the relevant first advertisement 127. The NEs 104-114 may then flood the network 100 with the information received from the central entity 103, to ensure that all NEs

104-114 maintain a consistent view of the service groups 130 provisioned in the network 100.

[00106] After each of the NEs 104-114 have updated the local databases to include the information from the first advertisement 127, NE 109 may obtain a second advertisement 137 including the service group ID 140. The second advertisement 137 may be received from the central entity 103, an NE external to the network, or an operator of the network 100. In another case, NE 109 may generate the second advertisement 137. In this way, obtaining the second advertisement 137 may refer to receiving the second advertisement 137 or generating the second advertisement 137.

[00107] As shown by FIG. 1A, the second advertisement 137 includes the service group ID 140 identifying the service group 130 and a source NE ID 190 identifying a source NE 109 from which the second advertisement 137 originated. The source NE ID 190 carries a label, address, or ID identifying the source NE 109 from which the second advertisement 137 originated. As should be appreciated, the second advertisement 137 may contain other information not shown in FIG. 1 A.

[00108] The second advertisement 137 may contain information pertinent to the NEs 109, 108,

107, 106 110, 111, and 112 within the service group 130 or relevant to the application or service associated with the service group 130. For example, the second advertisement 137 may contain a security key associated with the service group 130, and in particular, the first PPR and the second

PPR.

[00109] Upon obtaining the second advertisement 137, NE 109 initiates service group flooding of the second advertisement 137. Service group flooding refers to the flooding of the second advertisement 137 to only to neighboring NEs 104-114 that are members of the service group 130.

In this case, NE 109 first updates the local databases to include the information from the second advertisement 137, and then floods the first advertisement 127 to NEs 108 and 110, both of which are also members of the service group 130. NE 109 does not forward the second advertisement

137 to neighboring NE 104 since neighboring NE 104 is not a member of the service group 130.

[00110] NEs 108 and 110 similarly update the local databases to include the information from the second advertisement 137. NE 108 floods the second advertisement 137 to neighboring NE

107, which is also a member of the service group 130. NE 110 floods the second advertisement

137 to neighboring NE i l l, which is also a member of the service group 130. NEs 107 and i l l similarly update the local databases to include the information from the second advertisement 137.

NE 107 forwards the second advertisement 137 to neighboring NE 106, which is also a member of the service group 130. NE 111 forwards the second advertisement 137 to neighboring NE 112, which is also a member of the service group 130. However, NE 112 is not part of the first PPR or the second PPR. As described above, the central entity 103 included the NE 112 in the service group 130 for topological continuity within the service group 130.

[00111] However, when the central entity 103 adds NE 112 to the service group 130 solely for the sake of topological continuity, the added NE 112 makes the service group 130 vulnerable to unwanted attacks or manipulation of secure information. For example, when the second advertisement 137 includes a security key that is specific to the first and second PPR, the NE 112 has the ability to inject information into the second advertisement 137, remove the security key from the second advertisement 137, or otherwise manipulate the security key before forwarding the second advertisement 137 to neighboring NE 106. Regardless, NE 106 is configured to accept the second advertisement 137 from neighboring NE 1 12 and continue to flood the second advertisement 137 through the service group 130 because neighboring NE 112 is a member of the service group 130.

[00112] Disclosed herein are embodiments directed to verifying the second advertisement 137 that may be received from another NE 112 before processing the second advertisement 137 or continuing to flood the second advertisement 137 to other NEs in the service group 130. When NE

106 (e.g., the receiving NE 106) receives the second advertisement 137 from NE 112, NE 106 determines that NE 112 is a member of the service group 130, but not on either the first PPR or the second PPR included in the service group 130. In an embodiment, NE 106 verifies the second advertisement 137 based on a portion of a path along which the second advertisement 137 is received, the NEs 109, 108, 107, 106 110, 111, and 112 in the service group 130, the source NE

109 indicated by the source NE ID 190, and the topology of the network 100. In an embodiment, the portion of the path along which the second advertisement 137 is received refers to the NE(s) from which the second advertisement 137 is received, which in this example is NE 112. More particularly, the portion of the path can be a final hop to the receiving NE 106, directly from NE

112, in this example. The NE 106 can identify this final hop independently, for example by identifying which port of the NE receives the advertisement 137. The topology of the network 100 may be stored in the LSDB of NE 106.

[00113] In an embodiment, the receiving NE 106 determines whether the portion of the path along which the second advertisement 137 is received (e.g., NE 112) is on a path between the source NE 109 and the receiving NE 106 based on the topology of this network. In this case, NE

112 is on a path between the source NE 109 to the receiving NE 106, as shown by the bolded arrows in FIG. 1A (through NEs 109, 110, 111, 112, and 106). In an embodiment, NE 106 may determine this path between the source NE 109 to the receiving NE 106 based on the topology of the network 100. In addition, NE 112 is a member of the service group 130.

[00114] Based on these determinations in the example shown in FIG. 1A, NE 106 determines that the second advertisement 137 received from NE 112 is valid, verifying the advertisement. NE

106 updates the local databases to include the information from the second advertisement 137. NE

106 may then flood the second advertisement 137 to other NEs in the network 100 that are members of the service group 130, if any of the NEs in the service group 130 have not yet received the second advertisement 137.

[00115] FIG. 1B is another schematic diagram illustrating a network 150 configured to implement network connectivity verification according to various embodiments of the disclosure.

Network 150 is similar to network 100, except that network 150 includes an additional NE 115 coupled to NE 106 via link 123. NE 115 is similar to NEs 104-114.

[00116] The service group 130 includes the NE 115, and the second PPR includes the NE 115.

In this way, the first advertisement 127 includes an NE ID 147 identifying the NE 115 as being a member of the service group 130. In an embodiment, the first advertisement 127 may also include a PPR-PDE 143B indicating the NE IDs 147 identifying the NE 115 as being on the second PPR.

In an embodiment, the NEs 104-115 in network 150 maintain an LSDB indicating a topology of the network 150, which further indicates that NE 115 is coupled to NE 106 via link 123.

[00117] In the example shown in FIG. IB, NE 115 sends the second advertisement 137 to NE

106, in which the second advertisement 137 includes the source NE ID 190. The source NE ID

190 indicates that the second advertisement 137 originated at source NE 109. After NE 106 receives the second advertisement 137, NE 106 again verifies the second advertisement 137 based on a portion of a path along which the second advertisement 137 is received, the NEs 109, 108,

107, 106 110, 111, 1 12, and 115 in the service group 130, and the topology of the network 150.

[00118] In an embodiment, the receiving NE 106 determines whether the portion of the path along which the second advertisement 137 is received (e.g., NE 115) is on a path between the source NE 109 and the receiving NE 106 based on the topology of this network. In this case, NE

106 determines, based on the topology of the network 150, that NE 115 is not on a path from the source NE 109 to the receiving NE 106, even though NE 115 is a member of the service group

130. There are multiple paths between source NE 106 to receiving NE 109. For example, a first path between source NE 109 and receiving NE 106 includes NEs 109, 108, 107, and 106. A second path between source NE 109 and receiving NE 109 includes NEs 109, 110, 111, 112, and

106. A third path between source NE 106 and receiving NE 109 includes NEs 109, 110, 111, 1 12,

113, and 106. A fourth path between source NE 106 and receiving NE 109 includes NEs 109, 110,

111, 114, 113, and 106. However, NE 115 is not directly or indirectly connected to source NE 109 through any of these paths, except through NE 106 itself

[00119] In an embodiment, NE 106 determines the multiple paths between source NE 106 to receiving NE 109 based on the topology of the network 150 indicated in the LSDB stored at NE

106. For example, NE 106 determines the multiple paths between source NE 106 to receiving NE

109 using a depth first search (DFS) search of the network 150 using the topology of the network

150 indicated in the LSDB. NE 106 determines that the portion of the path along which the second advertisement 137 is received (e.g., NE 115) is not on a path from the source NE 109 to the receiving NE 106 (except through NE 106) using the DFS search of the network 150.

[00120] Based on these determinations in this example shown in FIG. IB, NE 106 determines that the second advertisement 137 received from NE 115 is not valid. NE 106 may discard or drop the second advertisement 137 to ensure that the second advertisement 137 does not continue to be flooded to the other NEs in the service group 130.

[00121] In some embodiments, a service group 130 may not be provisioned in the network 150.

In these embodiments, NEs 104-115 may still verify incoming second advertisements 137 based on a topology of the network 150 and a portion of a path along which the second advertisement 137 is received.

[00122] FIG. 1C is another schematic diagram illustrating a network 175 configured to implement connectivity verification according to various embodiments of the disclosure. Network

175 is similar to network 150, except that network 175 does not include a service group 130. In one embodiment, all of NEs 104-115 may be considered part of a single service group 130.

Further, the second advertisement 137 in FIG. 1 C does not include a service group ID 140. In the embodiment shown in FIG. 1C, the second advertisement 137 includes the source NE ID 190.

[00123] The first and second PPR described in FIG. IB is provisioned in network 175 of FIG.

1C. In this way, the first advertisement 127 does not include the service group set ID 145 or the service group ID 140. Instead, the first advertisement 127 includes the PPR-ID 142 A identifying the first PPR and the PPR PDEs 143 A indicating the NE IDs 147 identifying each of the NEs 109,

108, 107, and 106 in the first PPR. The first advertisement 127 also includes PPR-ID 142B identifying the second PPR and PPR-PDEs 143B indicating the NE IDs 147 identifying each of the

NEs 109, 1 10, 1 1 1, 106, and 1 1 15 in the second PPR. In an embodiment, the NEs 104-115 in network 175 maintain an LSDB indicating a topology of the network 175, which further indicates that NE 115 is coupled to NE 106 via link 123.

[00124] In the example shown in FIG. 1C, NE 115 sends the second advertisement 137 to NE

106, in which the second advertisement 137 includes the source NE ID 190. The source NE ID 190 indicates an ID, label, or address identifying the NE from which the second advertisement 137 originated. The source NE ID 190 indicates that the second advertisement 137 originated at source

NE 109. After NE 106 receives the second advertisement 137, NE 106 verifies the second advertisement 137 based on the source NE ID 190, a portion of a path along which the second advertisement 137 is received, and the topology of the network 165. In this embodiment, the verification of the second advertisement 137 is not based on members of a service group since a service group is not provisioned in the network 175.

[00125] In an embodiment, the receiving NE 106 determines whether the portion of the path along which the second advertisement 137 is received (e.g., NE 115) is on a path between the source NE 109 and the receiving NE 106 based on the topology of this network. In this case, NE

106 determines, based on the topology of the network 175, that NE 115 is not on a path from the source NE 109 to the receiving NE 106. There are multiple paths between the source NE 106 to receiving NE 109. For example, a first path between source NE 109 and receiving NE 106 includes NEs 109, 108, 107, and 106. A second path between source NE 109 and receiving NE

109 includes NEs 109, 1 10, 1 11, 112, and 106. A third path between source NE 106 and receiving

NE 109 includes NEs 109, 110, 111, 112, 113, and 106. A fourth path between source NE 106 and receiving NE 109 includes NEs 109, 110, 111, 114, 113, and 106. However, NE 115 is not directly or indirectly connected to source NE 109 through any of these paths, except through NE 106 itself.

[00126] Based on these determinations, NE 106 determines that the second advertisement 137 received from NE 115 is not valid. NE 106 may discard or drop the second advertisement 137 to ensure that the second advertisement 137 does not continue to be flooded to the other NEs in the service group 130. In this way, FIG. 1C shows that NEs 104-115 are configured to verify incoming second advertisements 137 based on a portion of a path along which the second advertisement 137 is received and the topology of the network 165, regardless of whether the NE

104-115 is part of a service group. As shown by FIG. 1C, the connectivity verification embodiments disclosed herein are applicable to all NEs 104-115 in a network 175 implementing an

IGP flooding mechanism.

[00127] The embodiments disclosed herein enable a receiving NE 106 to verify an incoming advertisement before flooding the advertisement through the service group 130. As such, the embodiments disclosed herein are advantageous in that a receiving NE 106 is capable of adding an additional layer of security to the flooding of information in service groups 130 to prevent malicious attacks or invalid data from being flooded through the service group 130. By preventing malicious attacks on advertisements flooded through a service group 130 and preventing invalid data from being flooded through a service group 130, the embodiments disclosed herein enable a more efficient and effective way of implementing service groups 130 in a network 100, 150, or

175.

[00128] FIG. 2 is a schematic diagram of an NE 200 suitable to implement network connectivity verification according to various embodiments of the disclosure. In an embodiment, the NE 200 may be implemented as any one of NEs 104-114 or the central entity 103.

[00129] The NE 200 comprises ports 220, transceiver units (Tx/Rx) 210, a processor 230, and a memory 260. The processor 230 comprises a service group module 235. Ports 220 are coupled to Tx/Rx 210, which may be transmitters, receivers, or combinations thereof. The

Tx/Rx 210 may transmit and receive data via the ports 220. Processor 230 is configured to process data. Memory 260 is configured to store data and instructions for implementing embodiments described herein. The NE 200 may also comprise electrical-to-optical (EO) components and optical-to-electrical (OE) components coupled to the ports 220 and Tx/Rx 210 for receiving and transmitting electrical signals and optical signals.

[00130] The processor 230 may be implemented by hardware and software. The processor

230 may be implemented as one or more central processing unit (CPU) and/or graphics processing unit (GPU) chips, logic units, cores (e.g., as a multi-core processor), field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and digital signal processors (DSPs). The processor 230 is in communication with the ports 220, Tx/Rx

210, and memory 260. The service group module 235 is implemented by the processor 230 to execute the instructions for implementing various embodiments discussed herein. For example, the service group module 235 is configured execute instructions stored at the memory 260, which cause the processor to be configured to forward the first advertisement 127 and the second advertisement 137 to only the NEs 104-114 in a service group 130. The service group module

235 is configured execute instructions stored at the memory 260, which cause the processor to be configured to verify received advertisements 137. The inclusion of the service group module

235 provides an improvement to the functionality of the NE 200. The service group module 235 also effects a transformation of NE 200 to a different state. Alternatively, the service group module 235 is implemented as instructions stored in the memory 260.

[00131] The memory 260 comprises one or more of disks, tape drives, or solid-state drives and may be used as an over-flow data storage device, to store programs when such programs are selected for execution, and to store instructions and data that are read during program execution.

The memory 260 may be volatile and non-volatile and may be read-only memory (ROM), random-access memory (RAM), ternary content-addressable memory (TCAM), and static random-access memory (SRAM). [00132] In an embodiment, the memory 260 is configured to store service group capability information 265, service group ID 140, service group set IDs 145, service group databases 229, service group neighbors 280, LSDB 273 (shown in FIG. 2 as the“link-state database 273”), routing table 276, service group mappings 279, verification criteria 222, and negotiation policies

224. The service group capability information 265 is a flag indicating whether NE 200 is capable of implementing service group flooding and the network connectivity verification embodiments disclosed herein. The service group ID 140 is a value uniquely identifying a service group 130. The service group set ID 145 is a value uniquely identifying a service group set.

[00133] A service group database 229 stores information received from another NE 200 indicating a particular service group ID 140. In an embodiment, NE 200 maintains a service group database 229 for each service group 130 in which the NE 200 is a member. For example,

NEs 109, 108, 107, 106 110, 111, and 112 each maintain a service group database 229 for service group 130, corresponding to service group ID 140. The service group database 229 stores the information from the second advertisement 137. A service group neighbor 280 refers to one or more NEs 104-115 that neighbor a respective NE 104-115 and is a member of a common service group 130.

[00134] The LSDB 273 stores information describing a topology of network 100, 150, or 175.

The LSDB 273 stores link state information received from advertisements flooded through the network 100, 150, or 175 by each of NEs 104-115. This way, each of the NEs 104-115 in network 100, 150, or 175 maintains the same LSDB 273 indicating the topology of the network

100, 150, or 175. The routing table 276 includes routing information describing a next hop to every destination in the network 100, 150, or 175. [00135] The service group mappings 279 may include mappings between an application or service 277, one or more service group IDs 140 (shown in FIG. 2 as“SG ID 140”), and one or more NE IDs 147. In an embodiment, the memory 260 of the central entity 103 stores the service group mappings 279. In an embodiment, the service group mappings 279 are part of the

LSDB 273.

[00136] The verification criteria 222 (also referred to as a“flooding option”) refer to the types of paths, or path types, that are used by an NE 200 to verify the second advertisement 137. The verification criteria 222 are further described below with reference to FIGS. 4 and 5A-B.

[00137] The negotiation policy 224 (also referred to as a“negotiation rule”) refers to a rule by which to select a single path type from the path types included in the verification criteria 222 for all the NEs in a service group 130. The negotiation policy 224 is further described below with reference to FIGS. 6 and 7A-B.

[00138] It is understood that by programming and/or loading executable instructions onto the

NE 200, at least one of the processor 230 and/or memory 260 are changed, transforming the NE

200 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 is 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.

[00139] FIG. 3 is a schematic diagram of another network 300 configured to implement network connectivity verification according to various embodiments of the disclosure. Network

300 may also be configured to implement an OSPF protocol.

[00140] As shown by FIG. 3, network 300 includes NEs 301-308, interconnected by links 323.

Each of NEs 301-308 is similar to NEs 104-115. Links 323 are each similar to links 123. In an embodiment, each of NEs 301-308 maintains a similar LSDB 273 indicating a network topology of network 300.

[00141] In the example shown in FIG. 3, NEs 301, 302, 303, 304, 305, and 306 are members of a service group 130. The service group 130 may be associated with a PPR identified by PPR-ID

142. The PPR may be a path including NE 301, 302, 304, 305, and 306, as indicated by the square around NEs 301, 302, 304, 305, and 306. Similar to the situation described above with reference to

FIG. 1A, NE 303 may have been added to the service group 130 to ensure topological continuity between the member NEs 301, 302, 303, 304, 305, and 306 of the service group 130. NEs 307 and

308 are not members of the service group 130. [00142] The first advertisement 127 describing the service group 130 includes the service group

ID 140 and NE IDs 147 describing NEs 301, 302, 303, 304, 305, and 306. In an embodiment, the first advertisement 127 also includes the PPR-ID 142 identifying the PPR and PPR-PDEs 143 indicating NE IDs 147 identifying NEs 301, 302, 304, 305, and 306.

[00143] The first advertisement 127 is flooded to all the NEs 301-308 in the network 300. In this way, each of the NEs 301-308 maintains the same data describing the service group 130. This data may include at least one of the service group ID 140 identifying the service group 130, NE

IDs 147 of NEs 301, 302, 303, 304, 305, and 306, and information describing the PPRs associated with the service group 130.

[00144] Subsequently, a second advertisement 137 may be sent through the network 300. The second advertisement 137 includes the service group ID 140 and the source NE ID 190. As should be appreciated, the second advertisement 137 may contain other information not shown in FIG. 3.

[00145] In the example shown in FIG. 3, the second advertisement 137 originates from source

NE 301, and a label, address, or ID of NE 301 may be carried in the source NE ID 190. The source NE 301 may have generated the second advertisement 137. Alternatively, the source NE

301 may have received the second advertisement 137 from the central entity 103, another NE within or external to the network 300, or an operator of the network 300. In the embodiment shown in FIG. 3, NEs 302-306 are configured to determine whether to verify the second advertisements 137 based on the service group 130, a network topology, and a portion of a path along which the second advertisement 137 is received.

[00146] In one example, as shown by bolded arrow 345, NE 304 receives the second advertisement 137 via link 323 from NE 303. Although NE 303 is not on the PPR associated with the service group 130, NE 303 is still a member of the service group 130 for topological continuity. NE 303 is then permitted to forward the second advertisement 137 to NE 304. NE 304 may also determine, based on the topology of the network 300, whether the portion of the path (e.g., NE

303) is on a path between the source NE 301 (indicated by the source NE ID 190) and the receiving NE 304. As shown by FIG. 3, NE 303 is on a path from source NE 301 to NE 304

(through NEs 301, 302, 303, and 304). Therefore, in this example, NE 304 determines that the second advertisement 137 received from NE 303 is valid. NE 304 may then flood the second advertisement 137 to NE 305, which is also a member of the service group 130.

[00147] In another example, as shown by bolded arrow 347, NE 304 receives the second advertisement 137 via link 323 from NE 305. NE 305 is a member of the service group 130 and is on the PPR associated with the service group 130. NE 304 may determine, based on the topology of the network 300, whether the portion of the path (e.g., NE 305) is on a path between the source

NE 301 and the receiving NE 304. As shown by FIG. 3, NE 305 is not on a path from source NE

301. Rather, NE 305 is not directly or indirectly connected to source NE 301, except through NE

304 itself. In this way, NE 305 could not have received the second advertisement 137 from source

NE 301 unless NE 305 received the advertisement from NE 304 itself, and then transmitted it back to NE 304. Therefore, in this example, NE 304 may discard or drop the second advertisement 137 to ensure that the second advertisement 137 does not continue to be flooded to the other NEs 305 and 306 in the service group 130.

[00148] In some embodiments, NE 304 may determine that messages received from NE 303 should not be trusted. In this case, a direct adjacency may be established between NE 304 and NE

302. The central entity 103 or an operator of the network 300 may establish the direct adjacency between NE 304 and NE 302 using a reliable transport connection, such as a tunnel or a virtual link. When a direct adjacency is established between NE 304 and NE 302, NE 304 may receive messages or advertisements directly from NE 302. However, NE 304 still verifies advertisements received from NE 302 based on the service group 130, the source NE indicated by the source NE

ID 190, the network topology, a portion of the path along which a second advertisement 137 is received, and a path from the source NE to the NE 304.

[00149] In the examples described in FIG. 3, NE 304 verifies the second advertisement 137 based on a path from source NE to the NE 304, in which the path is the PPR. Referring back to the first example, when NE 304 receives the second advertisement 137 from NE 303, then the link from NE 303 to NE 304 is the portion of the path along which the second advertisement 137 is received. In this example, NE 304 verifies that NE 303 is on a path from NE 301 to NE 304, in which the path is along the PPR between the source NE 301 and the receiving NE 304. However, there may be multiple paths between source NE 301 and NE 304. As shown by FIG. 3, there are two paths between NE 301 to NE 304. The first path is along the PPR, which includes NEs 301,

302, 303, and 304. The other path may be, for example, the shortest path, which includes NEs 301,

307, and 304. This other path may be considered the shortest path because this path includes the least number of hops between the source NE 301 and the NE 304. In these cases where there may be multiple paths between the source NE 301 and the NE 304, NE 304 advertises criteria, such as one or more types of paths, that NE 304 uses to verify the second advertisement 137.

[00150] FIG 4 is a schematic diagram illustrating the network 300 of FIG. 3, further configured to advertise verification criteria 222 to implement network connectivity verification according to various embodiments of the disclosure. As shown by FIG. 4, network 300 includes NEs 301-308 interconnected by links 323.

[00151] The first advertisement 427 A-H in FIG. 4 is similar to the first advertisement 127 described with reference to FIG. 3, which is flooded to all NEs 301-307 in the network 300. However, unlike first advertisement 127, the first advertisement 427 A-H additionally includes verification criteria 222, which refers to path types that are used by NEs 301-308 sending the first advertisement 127 to verify incoming second advertisements 437.

[00152] In an embodiment, the verification criteria 222 is determined by the central entity 103 and transmitted to at least one NE 301-308 in the network 300 via central entity-to-NE link 125. In another embodiment, an operator of network 300 pre-configures each of NEs 301-308 to verify incoming second advertisements 437 based on the verification criteria 222.

[00153] After each NE 301-308 obtains the verification criteria 222 relevant to the respective

NE 301-308, each NE 301-308 floods a first advertisement 427 A-H to all other NEs 301-308 in the network 300. Each first advertisement 427 A-H includes a service group ID 140 if the NE 301-308 sending the first advertisement 427 A-H is a member of the service group 130. In an embodiment, each first advertisement 427 A-H may also include the NE IDs 147 A-N identifying the NEs 301-

306 in the service group 130. In an embodiment, each first advertisement 427A-H may also include the verification criteria 222 used by the NE 301-308 sending the first advertisement 427 A-

H.

[00154] For example, NE 301 sends the first advertisement 427A to neighboring NEs 302 and

307. The first advertisement 427 A includes the service group ID 140 identifying the service group

130 including NE 301. In an embodiment, the first advertisement 427 A may also include NE IDs

147 A-N identifying NEs 301-306. The first advertisement 427A may also include the verification criteria 222 indicating one or more path types that NE 301 uses to verify subsequently received second advertisements 437. NEs 302-306 may send similar first advertisements 427B-F. Except that each of the first advertisements 427B-F include the verification criteria 222 indicating one or more path types that the respective NE 302-306 sending the first advertisement 427B-F uses to verify subsequently received second advertisements 437.

[00155] NEs 307 and 308 are not members of the service group 130. Therefore, the first advertisement 427G sent by NE 307 does not include the service group ID 140 or the NE IDs

147A-N. However, the first advertisement 427G may still include the verification criteria 222 identifying one or more path types that NE 307 uses to verify subsequently received second advertisements 437. Similarly, first advertisement 427H sent by NE 308 does not include the service group ID 140 or the NE IDs 147A-N. However, the first advertisement 427H may still include the verification criteria 222 identifying one or more path types that NE 308 uses to verify subsequently received second advertisements 437.

[00156] In some embodiments, the verification criteria 222 includes predefined encoding values that correspond to one or more different path types. Each NE 301-308 in the network 300 may store a database indicating a mapping between each predefined encoding value and a different path type. For example, the database may include the mappings between a path type, an encoding value, and a receiving NE process method from Table 1 :

Table 1

[00157] As shown in Table 1, the encoding value of“0” does not map to any path type. Instead, the encoding value of“0” indicates that an NE, such as NE 304, does not perform verification on any incoming second advertisements 437. In this embodiment, when NE 304 obtains (e.g., generates or receives) the first advertisement 427A-H (hereinafter referred to as the “first advertisement 427”), the verification criteria 222 in the first advertisement 427 includes the encoding value of“0.” The receiving NE processing method corresponding to the encoding value of“0” indicates that NE 304 is configured to accept all second advertisements 437 received from neighboring NEs 303, 305, 307, and 308. In one embodiment, when a first advertisement 427 does not include verification criteria 222, the receiving NE 304 may also be configured to accept all second advertisements 437 received from neighboring NEs 303, 305, 307, and 308. While Table 1 indicates that the encoding value of“0” maps to the case in which the NE 301-308 does not verify incoming second advertisements 437, it should be appreciated that any encoding value may represent the case in which the NE 301-308 does not verify incoming second advertisements 437.

[00158] The encoding value of“1” maps to the path type of strict paths, indicating that an NE, such as NE 304, verifies incoming second advertisements 437 based on strict paths only. In this embodiment, when NE 304 obtains the first advertisement 427, the verification criteria 222 in the first advertisement 427 includes the encoding value of“1.” The receiving NE processing method corresponding to the encoding value of“1” indicates that NE 304 verifies an incoming second advertisement 437 by checking that the portion of the path along which the second advertisement

437 is received is on a strict path from the source NE of the second advertisement 437. In an embodiment, the second advertisement 437 received is along a strict path between the source NE

302 of the second advertisement 437 and NE 304 only when the portion of the path (e.g., NE 303) from which the second advertisement 437 is received is also a member of the service group 130.

The service group ID 140 in the second advertisement 437 may be used to determine whether the neighboring NE 303 is a member of the service group 130. While Table 1 indicates that the encoding value of“2” maps to strict paths, it should be appreciated that any encoding value may represent strict paths.

[00159] The encoding value of“2” maps to the path type of best paths (also referred to herein as

“shortest path first (SPF) calculated path”), indicating that an NE, such as NE 304, verifies incoming second advertisements 437 based on best paths only. In this embodiment, when NE 304 obtains the first advertisement 427, the verification criteria 222 in the first advertisement 427 includes the encoding value of“2.” The receiving NE processing method corresponding to the encoding value of“2” indicates that NE 304 verifies an incoming second advertisement 437 by checking that the portion of the path along which the second advertisement 437 is received is on a best path from the source NE of the second advertisement 437. To determine a best path to each

NE 301-308 in the network 300, each NE 301-308 constructs a shortest path tree to each of the other NEs 301-308 in the network 300, and uses this shortest path tree to construct a routing table

276 describing the best path to each other NE 301-308 in the network 300. For example, a shortest path tree may be computed for each NE 301-308 using a Dijkstra’s Shortest Path First (SPF) algorithm. As another example, each NE 301 -308 determines the best path to each other NE 301-

308 in the network 300 based on the costs of each of the links 323 interconnecting NEs 301-308 in the network 300. For example, a best path between NEs 302 and 304 flows from {NE 302, NE

303, and NE 304}, as shown by bolded arrow 445. NE 304 verifies incoming second advertisements 437 received from NE 303 along the best path, in which the source of the second advertisement 437 is NE 302. However, NE 304 discards or discontinues service group flooding of incoming second advertisements 437 received from NE 307 or NE 305. While Table 1 indicates that the encoding value of“2” maps to best paths, it should be appreciated that any encoding value may represent best paths. [00160] The encoding value of“3” maps to the path type of matching best paths, indicating that an NE, such as NE 304, verifies incoming second advertisements 437 by checking the portion of the path along which the second advertisement 437 is received, and conditionally accepting a second advertisement 437 received along a matching best path if the second advertisement 437 was also received along the best path. In this embodiment, when NE 304 obtains the first advertisement 427, the verification criteria 222 in the first advertisement 427 includes the encoding value of“3.” As used herein, a matching best path is a path that is different from the best path.

For example, the best path between NEs 302 and 304 flows from {NE 302, NE 303, to NE 304}, which may be the best path because it contains the least number of hops between NEs 302 and 304, as shown by bolded arrow 445. In this example, a matching best path between NEs 302 and 304 flows from {NE 302, NE 301, NE 307, to NE 304], as shown by bolded arrow 450. The receiving

NE processing method corresponding to the encoding value of“3” indicates that NE 304 verifies an incoming second advertisement 437 received from NE 307 along the matching best path if the second advertisement 437 was also received from NE 303 along the best path.

[00161] In some cases, NE 304 receives the second advertisement 437 from both NE 303 along the best path and NE 307 along the matching best path, such that NE 304 retains two copies of the second advertisements 437. This redundancy of receiving the second advertisement 437 from both the best path and the matching best path enables for a faster recovery mechanism if the best path were to fail. For example, if the best path between NEs 302 and 304 fails, then NE 304 still receives and retains the second advertisement from NE 307 along the matching best path, without the need for the network to converge and reconfigure a new best path. In this case, the copy of the second advertisement 437 received from NE 303 along the best path may be deleted, while the copy of the second advertisement 437 received from NE 307 along the matching best path may be retained. While Table 1 indicates that the encoding value of“3” maps to matching best paths, it should be appreciated that any encoding value may represent matching best paths.

[00162] The encoding value of“4” maps to the path type of backup paths, indicating that an

NE, such as ME 304, verifies incoming second advertisements 437 by checking the portion of the path along which the second advertisement 437 is received and determining whether the second advertisement 437 was received along a backup path of the best path. In this embodiment, when

NE 304 obtains the first advertisement 427, the verification criteria 222 in the first advertisement

427 includes the encoding value of“4.” As used herein, backup path refers to a path that is computed to be the shortest path when a link or node along the best path fails, making the backup path essentially the next best path when the best path fails. For example, the best path between

NEs 302 and 304 flows from {NE 302, NE 303, to NE 304}, as shown by bolded arrow 445. In this example, when link 323 between NEs 302 and 303 fails, the backup path to the best path between NEs 302 and 304 flows from {NE 302, NE 301, NE 307, to NE 304}, as shown by bolded arrow 450. The receiving NE processing method corresponding to the encoding value of“4” indicates that NE 304 verifies an incoming second advertisement 437 received from NE 307 along the backup path, regardless of whether the incoming second advertisement 437 was also received from NE 303 along the best path. While Table 1 indicates that the encoding value of“4” maps to backup paths, it should be appreciated that any encoding value may represent backup paths.

[00163] The encoding value of“5” maps to the PPRs, indicating that an NE, such as NE 304, verifies incoming second advertisements 437 by checking the portion of the path along which the second advertisement 437 is received and determining whether the second advertisement 437 was received along a PPR. In this embodiment, when NE 304 obtains the first advertisement 427, the verification criteria 222 in the first advertisement 427 includes the encoding value of“5.” A PPR refers to a custom path or any other path that may or may not deviate from the best path computed between two NEs or between a source and destination. The PPRs are determined based on an application or server request for a path between two NEs 301-308 or between a source and destination that satisfies one or more network characteristics or service requirements. For example, a PPR may be provisioned between NEs 302 and 304, in which the PPR flows from {NE

302, NE 301, NE 307, and NE 304}, as shown by bolded arrow 450. The receiving NE processing method corresponding to the encoding value of“5” indicates that NE 304 verifies an incoming second advertisement 437 received from NE 307 along the PPR. When NE 304 only verifies advertisements using the PPR, then NE 304 would discard and discontinue flooding of an incoming second advertisement 437 received from NE 303 along the best path. While Table 1 indicates that the encoding value of“5” maps to PPRs, it should be appreciated that any encoding value may represent PPRs.

[00164] The encoding value of“6” maps to the traffic engineered (TE) paths, indicating that an

NE, such as NE 304, verifies incoming second advertisements 437 by checking the portion of the path along which the second advertisement 437 is received and determining whether the second advertisement 437 was received along a TE path. In this embodiment, when NE 304 obtains the first advertisement 427, the verification criteria 222 in the first advertisement 427 includes the encoding value of“6.” A TE path may be path provisioned by a central entity 103 or an operator of the network 300 based on network constraints within the network 300. The TE path may be different from or the same as the best path, backup path, or PPR between two NEs 301-308. For example, a TE path may be provisioned between NEs 302 and 304, in which the PPR flows from

{NE 302, NE 301, NE 307, and NE 304}, as shown by bolded arrow 450. The receiving NE processing method corresponding to the encoding value of“6” indicates that NE 304 verifies an incoming second advertisement 437 received from NE 307 along the TE path. When NE 304 only verifies advertisements using the TE path, then NE 304 would discard and discontinue flooding of an incoming second advertisement 437 received from NE 303 along the best path. While Table 1 indicates that the encoding value of“6” maps to TE paths, it should be appreciated that any encoding value may represent TE paths.

[00165] As shown by Table 1, certain other encoding values may be reserved for future use for various different path types. It should be appreciated that Table 1 may not necessarily be stored at each of the NEs 301-308. Instead, each of NEs 301-308 may be pre-configured by a central entity

103 or an operator of the network 300 with the verification criteria 222 corresponding to the path types used by the respective NE 301-308 to verify incoming second advertisements 437. NEs 301-

308 may maintain information describing the verification criteria 222 for each NE 301-308 in network 300 after receiving the first advertisement 427 from all the NEs 301-308.

[00166] FIGS. 5A-B are schematic diagrams illustrating examples of the first advertisement

427 A-H (referred to hereinafter as“first advertisement 427”) according to a first embodiment of the disclosure. Specifically, FIG. 5 A is a schematic diagram illustrating data included within the first advertisement 427 that flooded through network 300 of FIG. 4, and FIG. 5B is a schematic diagram illustrating the first advertisement 427 encoded as a portion of an LSA 550.

[00167] Referring now to FIG. 5A, the first advertisement 427 comprises at least one of a capability flag 503, one or more service group set IDs 145, one or more service group IDs 140, one or more NE IDs 147, and verification criteria 222. In an embodiment, the capability flag 503 is a flag, or a bit, that is set to indicate that an NE 301-308 sending the first advertisement 427

(e.g., sending NE 301-308) is capable of implementing service group flooding and network connectivity verification according to the embodiments disclosed herein. [00168] The service group IDs 140 identify service groups 130 to which the sending NE 301-

308 belongs. In an embodiment, the service group IDs 140 are values uniquely identifying a service group 130. The service group ID 140 may be a 4 bit value, a 6 bit value, or a 32 bit value, depending on the application and use of the service group 130, or the network constraints.

The service group set IDs 145 identify service group set to which the sending NE 301-308 belongs. The service group set ID 145 may also be a 4 bit value, a 6 bit value, or a 32 bit value, depending on the application and use of the servi ce group 130, or the network constraints. The first advertisement 427 may not necessarily include the service group set IDs 145 if the sending

NE 301-308 is not a member of a service group 130 that is also part of a service group set.

[00169] As described above, the verification criteria 222 indicates one or more encoding values representing a path type that is used by the sending NE 301-308 to verify incoming second advertisements 437. For example, the verification criteria 222 may indicate an encoding value representing a strict path, a best path, a matching best path, a backup path, a PPR, a TE path, or any other type of path that may connect a source of the second advertisement 437 to the sending NE 301-308.

[00170] Referring now to FIG. 5B, shown is a portion of the LSA 550 (which is referred to herein as the“LSA 550”). The LSA 550 may be encoded as part of a Router Information (RI) opaque LSA, according to IETF RFC 7770, entitled“Extensions to OSPF for Advertising

Optional Router Capabilities,” by A. Lindem, et al., dated February 2016, which is incorporated by reference in its entirety. It should be appreciated that LSA 550 may otherwise be any other type of LSA as defined for the OSPF protocol. [00171] The LSA 550 shown in FIG. 5B is a type-length-value (TLV) included within the body of the RI opaque LSA. The LSA 550 includes a type field 553, a length field 556, and one or more service grouping flooding options TLVs 559.

[00172] The type field 553 is a 16 bit field carrying a value indicating that the LSA 550 includes fields, such as the service grouping flooding options TLVs 559, which carry information related to service groups 130 and verification criteria 222. In an embodiment, the type field 553 may be set to 1, or any other value that is assigned to represent LSAs 550 that carry information related to service groups 130 and verification criteria 222. The length field

556 is a 16 bit field indicating a length of the service grouping flooding options TLVs 559.

[00173] The service grouping flooding options TLVs 559 includes a plurality of bits or fields that can indicate one or more service group IDs 140 and the verification criteria 222 of the sending NE 301-308. In an embodiment, the service grouping flooding options TLVs 559 may include a list of multiple service group-to-verification criteria mappings. Each service group-to- verification criteria mapping includes a mapping between a service group ID 140 and a verification criteria 222 for the service group 130 identified by the service group ID 140. That is, different service groups 130 have different service group IDs 140, and may also have different verification criteria 222. The verification criteria 222 may indicate one or more different path types used by the sending NE 301-308 to verify incoming second advertisements 437.

[00174] In some cases, an NE 301-308 may be configured to verify incoming second advertisements 437 based on multiple different path types. As such, a sending NE 301-308 may send a first advertisement 427 including verification criteria 222 for a service group ID 140, in which the verification criteria 222 includes multiple encoding values for multiple different path types. In this way, different NEs 301-308 within a single service group 130 may be configured to verify incoming second advertisements 437 based on multiple different path types.

[00175] However, NEs 301-306 within a single service group 130 should ideally verify incoming second advertisements 437 based on the same verification criteria 222 or the same path type to ensure that the level of security across the entire service group 130 is consistent. That is, if

NE 301 verifies incoming second advertisements 437 based on a best path, and NE 302 verifies incoming second advertisements 437 based on a PPR, then the service group 130 may be flooded with invalid information. To prevent this, NEs 301-308 may also advertise negotiation policies

224 in the first advertisement 427.

[00176] FIG. 6 is a schematic diagram illustrating the network 300 of FIG. 3, further configured to advertise negotiation policies 224 to implement network connectivity verification according to various embodiments of the disclosure. As shown by FIG. 6, network 300 includes NEs 301-308 interconnected by links 323.

[00177] The first advertisement 627 A-H in FIG. 6 is similar to the first advertisement 427A-H described with reference to FIG. 4, which is flooded to all NEs 301-308 in the network 300.

However, unlike first advertisement 427, the first advertisement 627 A-H additionally includes the negotiation policy 224, which refers to a policy by which to select a single path from the verification criteria 222 applicable to each of the NEs 301-306 in the service group 130.

[00178] In an embodiment, the negotiation policy 224 is determined by the central entity 103 and transmitted to at least one NE 301-308 in the network 300 via central entity-to-NE link 125. In another embodiment, an operator of network 300 pre-configures each of NEs 301-308 to verify incoming second advertisements 637 based on the verification criteria 222 and the negotiation policy 224 for a service group 130. [00179] As shown by FIG. 6, each NE 301-308 floods a first advertisement 627 A-H to all other

NEs 301-308 in the network 300. Each first advertisement 627 A-H includes a service group ID

140 if the NE 301-308 sending the first advertisement 627 A-H is a member of the service group

130. In an embodiment, each first advertisement 627 A-H may also include the NE IDs 147 A-N identifying the NEs 301-306 in the service group 130. Each first advertisement 627 A-N may also include the verification criteria 222 used by the NE 301-308 sending the first advertisement 427 A-

H.

[00180] In various embodiments, the first advertisement 627 A-H also includes the negotiation policy 224. The negotiation policy 224 represents a rule by which to select a single path type from the verification criteria 222 of all the NEs 301-306 in a service group 130. In an embodiment, each service group 130 may be assigned the same negotiation policy 224, for example, by the central entity 103 or an operator of the network 300.

[00181] For example, NE 301 sends the first advertisement 627A to neighboring NEs 302 and

307. The first advertisement 627 A includes the service group ID 140 identifying the service group

130 including NE 301. The first advertisement 627 A may also include NE IDs 427 A-N identifying NEs 301-306. The first advertisement 627A may also include the verification criteria

222 indicating multiple path types that NE 301 uses to verify subsequently received second advertisements 637. The first advertisement 627A may also include a negotiation policy 224 indicating how to select a single path type from the multiple path types indicated by the verification criteria 222. NEs 302-306 may send similar first advertisements 627B-F. However, each of the first advertisements 627B-F includes the verification criteria 222 indicating multiple path types that the NE 302-306 sending the first advertisement 627B-F uses to verify subsequently received second advertisements 637. In an embodiment, NEs 302-306 may send similar first advertisements 627B-F with the same negotiation policy 224 since NEs 302-306 are members of the same service group 130.

[00182] NEs 307 and 308 are not members of the service group 130. Therefore, the first advertisement 627G and 627H do not include the service group ID 140 or the NEs 147A-N.

However, the first advertisement 427G and 427H may still include the verification criteria 222 and the negotiation policy 224.

[00183] In some embodiments, the negotiation policy 224 includes predefined encoding values that correspond to a rule by which NEs 301-306 are to select a single path type from the verification criteria 222 applicable to each of the NEs 301-306 in the service group 130. Each NE

301-306 in the network 300 may store a database indicating a mapping between each predefined encoding value and a negotiation policy 224. For example, the database may include the mappings between a path type, an encoding value, and a receiving NE process method from Table 2:

Table 2

[00184] As shown in Table 2, the encoding value of“0” does not map to any negotiation policy

224. Instead the encoding value of“0” indicates than an NE, such as NE 304, does not perform verification on any incoming second advertisements 637. In this embodiment, when NE 304 obtains (e.g., generates or receives) the first advertisement 627 A-H (hereinafter referred to as the

“first advertisement 627”), the negotiation policy 224 in the first advertisement 627 includes the encoding value of“0.” The NE processing method corresponding to the encoding value of“0” indicates that NE 304 is configured to accept all second advertisements 637 received from neighboring NEs 303, 307, and 308. In one embodiment, when a first advertisement 627 does not include a negotiation policy 224, the receiving NE 304 is configured to accept all second advertisements 637 received from neighboring NEs 303, 307, and 308. While Table 1 indicates that the encoding value of“0” maps to the case in which the NE 304 does not verify incoming second advertisements 437, it should be appreciated that any encoding value may represent the case in which the NE 304 does not verify incoming second advertisements 437.

[00185] The encoding value of “1” maps to the negotiation policy 224 indicating that a matching path type is to be determined from the verification criteria 222 of all the NEs 301-306 in a service group 130. In this embodiment, when NE 304 obtains the first advertisement 627, the negotiation policy 224 in the first advertisement 627 includes the encoding value of“1.” The NE processing method corresponding to the encoding value of“1” indicates that NE 304 determines the path type that is commonly indicated in the verification criteria 222 of all the NEs 301-306 in the service group 130.

[00186] For example, NE 301 has verification criteria 222 indicating that NE 301 verifies incoming second advertisements 637 including the service group ID 140 of service group 130 based on best paths and PPRs. In this example, suppose NEs 302-304 each has verification criteria

222 indicating that NEs 302-304 verify incoming second advertisements 637 including the service group ID 140 of service group 130 based on best paths. Further, suppose NEs 305-306 each has verification criteria 222 indicating that NEs 305-306 verify incoming second advertisements 637 including the service group ID 140 of service group 130 based on best paths and TE paths.

[00187] In this example, all the NEs 301 -306 in the service group 130 determine the path type that is commonly indicated in the verification criteria 222 of all the NEs 301-306 in the service group 130 is the best path. As such, all the NEs 301-306 verify incoming second advertisements

637 based on whether the second advertisement 637 is received from a neighboring NE that is on the best path from a source NE 302 to the receiving NE 301-306. [00188] In some cases, there may be multiple path types that are commonly included between all the NEs 301-306 in the service group 130. For example, suppose NEs 302-304 each has verification criteria 222 indicating that NEs 302-304 verify incoming second advertisements 637 including the service group ID 140 of service group 130 based on best paths and PPRs. Further, suppose NEs 305-306 each has verification criteria 222 indicating that NEs 305-306 verify incoming second advertisements 637 including the service group ID 140 of service group 130 based on best paths, PPR paths, and TE paths.

[00189] In this example, all the NEs 301-306 in the service group 130 determine that there are multiple path types that are common amongst the verification criteria 222 of all the NEs 301-306 in the service group 130. These multiple path types include best paths and PPRs. In one embodiment, NEs 301-306 in network 300 may be configured determine a default path type by which to verify incoming second advertisements 637. For example, the default path type may be a best path, and as such, all the NEs 301-306 verify incoming second advertisements 637 based on whether the second advertisement 637 is received from a neighboring NE that is on the best path from a source NE 302 to the receiving NE 301-306.

[00190] In another embodiment, NEs 301-306 in network 300 may be configured select one of the matching path types in the verification criteria 222 of the service group 130 based on the encoding value. For example, NEs 301-306 may be configured to select the path type having the lowest encoding value, or to select the path type having the highest encoding value. Continuing with the example from above, if the NEs 301-306 are configured to select the path type having the lowest encoding value, then the NEs 301 to 306 select the best path having the encoding value of

“2,” instead of the PPR, which has the encoding value of“5.” In contrast, if the NEs 301-306 are configured to select the path type having the highest encoding value, then the NEs 301 -306 select the PPR having the encoding value of“5,” instead of the best path, which has the encoding value of“2.”

[00191] In yet another embodiment, the central entity 103 instructs each of the NEs 301-306 in network 300 to use a certain path type as the verification criteria 222 for all the NEs 301-306 in the service group 130 when there are multiple matching path types. For example, the central entity

103 may instruct each of the NEs 301-306 in the service group 130 to use the best path as the verification criteria 222.

[00192] In some cases, when the negotiation policy 224 indicates that a matching path type is to be determined from the verification criteria 222 of all the NEs 301-306 in a service group 130, a matching path type may not exist in the verification criteria 222 of all the NEs 301-306 in a service group 130. In this case, then it may be determined that the NEs 301 -306 of the service group 130 cannot validate second advertisements 637 sent to one another.

[00193] In an embodiment, the encoding value of “2” maps to a negotiation policy 224 indicating that a default path type may be used to verify incoming second advertisements 637 when a matching path type does not exist in the verification criteria 222 of all the NEs 301-306 in a service group 130. For example, NE 301 has verification criteria 222 indicating that NE 301 verifies incoming second advertisements 637 including the service group ID 140 of service group

130 based on best paths. In this example, suppose NEs 302-304 each has verification criteria 222 indicating that NEs 302-304 verify incoming second advertisements 637 including the service group ID 140 of service group 130 based on PPRs. Further, suppose NEs 305-306 each has verification criteria 222 indicating that NEs 305-306 verify incoming second advertisements 637 including the service group ID 140 of service group 130 based on TE paths. [00194] In this example, a matching path type does not exist in the verification criteria 222 of all the NEs 301-306 in a service group 130. In this case, NEs 301-306 in network 300 may be configured determine a default path type by which to verify incoming second advertisements 637 when the matching path type does not exist in the verification criteria 222 of all the NEs 301-306 in a service group 130. For example, the default path type may be a best path, and as such, all the

NEs 301-306 verify incoming second advertisements 637 based on whether the second advertisement 637 is received from a neighboring NE that is on the best path from a source NE 302 to the receiving NE 301-306.

[00195] In some embodiments, a default path type may be used as the negotiation policy 224 to verify incoming second advertisements 637 when a matching path type does not exist in the verification criteria 222 of all the NEs 301-306. In some embodiments, a default path type may also be used as the negotiation policy 224 when NEs 301-306 do not have a matching negotiation policy 224 (e.g., the negotiation fails). For example, when NEs 301 and 302 have different negotiation policies 224 and different verification criteria 222, NEs 301 and 302 may be configured to use a default path type to verify incoming second advertisements 637. The default path type may be preset, for example, by an operator of the network 300 or the central entity 103 of the network 300.

[00196] As shown by Table 2, certain other encoding values may be reserved for future use for various different path types. It should be appreciated that Table 2 may not necessarily be stored at each of the NEs 301-306. Instead, each of NEs 301-306 may be pre-configured by a central entity

103 or an operator of the network 300 with the negotiation policy 224 that may be used to verify incoming second advertisements 637 when the verification criteria 222 for a service group 130 includes multiple path types. NEs 301-306 may maintain information describing the negotiation policy 224 for each service group 130 in the network 300 after receiving the first advertisement

627 from all the NEs 301-308.

[00197] After all the NEs 301 -308 have received the first advertisement 627 A-H from all the

NEs 301-308 in the network 300, an NE 301-308 may determine a flooding path by which to forward a subsequent second advertisement 637 based on whether an NE 301-308 uses the path type corresponding to the flooding path to verify the second advertisement 637. NE 301-308 determines the flooding path by which to forward a second advertisement 637 based on the verification criteria 222 and the negotiation policy 224.

[00198] For example, after NE 302 has received the first advertisement 627 A and C-H from

NEs 301 and 303-308, NE 302 updates a local database to include the information from the first advertisement 627A and C-H. NE 302 may then obtain (e.g., receive or generate) a second advertisement 637 including the service group ID 140, which is intended to be flooded to only NEs

301 and 303-306 in the service group 130. Before beginning to flood the second advertisement

637 through the service group 130, NE 302 first determines the verification criteria 222 for each of the NEs 301 and 303-306 in the service group 130. NE 302 also determines a negotiation policy

224 for the service group 130.

[00199] When the verification criteria 222 indicates that all the NEs 301 and 303-306 in the service group 130 verify second advertisements 637 using a single path type, then NE 302 begins flooding the second advertisements 637 along a flooding path to NEs 301 and 303-306 based on the single path type. For example, if the single path type indicated in the verification criteria 222 is the best path, then NE 302 begins flooding the second advertisements 637 along a best path to NEs

301 and 303-306. [00200] In one case, the verification criteria 222 indicates that different NEs 301 and 303-306 in the service group 130 verify second advertisements 637 using different path types. For example,

NE 301 has verification criteria 222 indicating that NE 301 verifies incoming second advertisements 637 based on best paths and PPRs, NEs 302-304 each has verification criteria 222 indicating that NEs 302-304 verify incoming second advertisements 637 based on best paths, and

NEs 305-306 each has verification criteria 222 indicating that NEs 305-306 verify incoming second advertisements 637 based on best paths and TE paths. In this example, NE 302 determines the negotiation policy 224 for the service group 130. When the negotiation policy 224 indicates that a matching path type is to be determined from the verification criteria 222 of all the NEs 301-

306 in a service group 130, NE 302 determines that the best path is the path type that is commonly indicated in the verification criteria 222 of all the NEs 301-306 in the service group 130. NE 302 begins flooding the second advertisements 637 along a best path to NEs 301 and 303-306.

[00201] In another case, the verification criteria 222 indicates that different NEs 301 and 303-

306 in the service group 130 verify second advertisements 637 using different path types, and there are multiple matching pathing path types in the verification criteria 222 of the service group 130.

In this case, NE 301 determines a flooding path by which to flood the second advertisement 637 based on a network configuration of network 300. For example, in an embodiment in which a default path type is used in this situation, NE 301 begins flooding the second advertisements 637 along a flooding path determined based on the default path type to NEs 301 and 303-306. In an embodiment in which a path type is selected based on an encoding value of the verification criteria

222, NE 301 begins flooding the second advertisements 637 along a flooding path determined based on this path type to NEs 301 and 303-306. In an embodiment in which NE 301 receives a path type from the central entity 103 to use in this situation, NE 301 begins flooding the second advertisements 637 along a flooding path determined based on the instructed path type to NEs 301 and 303-306.

[00202] In another case, the verification criteria 222 indicates that different NEs 301 and 303-

306 in the service group 130 verify second advertisements 637 using different path types, and there are no matching path types indicated in the verification criteria 222 of the NEs 301 and 303-306 in the service group 130. In this case, NE 302 may determine that the second advertisement 637 may not be sent to the other NEs 301 and 303-306 in the service group 130. In another case, NE 301 may determine that the negotiation policy 224 indicates that a default path type may be used to verify incoming second advertisements 637 in this situation. In this case, NE 301 begins flooding the second advertisements 637 along a flooding path determined based on the default path type to

NEs 301 and 303-306.

[00203] FIGS. 7A-B are schematic diagrams illustrating examples of the first advertisement

627 A-H (referred to hereinafter as“first advertisement 627”) according to a first embodiment of the disclosure. Specifically, FIG. 7A is a schematic diagram illustrating data included within the first advertisement 627 that is flooded through network 300 of FIG. 6, and FIG. 7B is a schematic diagram illustrating the first advertisement 627 encoded as a portion of an LSA 750.

[00204] Referring now to FIG. 7 A, the first advertisement 627 comprises at least one of a capability flag 503, one or more service group set IDs 145, one or more service group IDs 140, one or more NE IDs 147, verification criteria 222, and a negotiation policy 224. In an embodiment, the capability flag 503 is a flag, or a bit, that is set to indicate that an NE 301-308 sending the first advertisement 627 (e.g., sending NE 301-308) is capable of implementing service group flooding and network connectivity verification according to the embodiments disclosed herein. [00205] The service group IDs 140 include one or more service group IDs 140 identifying service groups 130 to which the sending NE 301-308 belongs. The service group set IDs 145 include one or more service group set IDs 145 identifying the service group set to which the sending NE 301-308 belongs. The first advertisement 627 may not necessarily include the service group set IDs 145 if the sending NE 301-308 is not a member of a service group 130 that is also part of a service group set.

[00206] As described above, the verification criteria 222 indicates one or more encoding values representing a path type that is used by the sending NE 301-308 to verify incoming second advertisements 637. For example, the verification criteria 222 may indicate an encoding value representing a strict path, a best path, a matching best path, a backup path, a PPR, a TE path, or any other type of path that may connect a source of the second advertisement 637 to the sending NE 301-308.

[00207] The negotiation policy 224 indicates an encoding value representing a policy used to select a single path type from multiple path types that may be indicated in the verification criteria

222 of the NEs 301-306 in a service group 130. In an embodiment, the negotiation policy 224 may be shared among member NEs 301-306 of the service group 130.

[00208] Referring now to FIG. 7B, shown is a portion of the LSA 750 (which is referred to herein as the“LSA 750”). The LSA 750 may be encoded as part of a Router Information (RI) opaque LSA, according to IETF RFC 7770, entitled“Extensions to OSPF for Advertising

Optional Router Capabilities,” by A. Lindem, et al., dated February 2016. It should be appreciated that LSA 750 may otherwise be any other type of LSA as defined for the OSPF protocol. [00209] The LSA 750 shown in FIG. 7B is a TLV included within the body of the RI opaque

LSA. The LSA 750 includes a type field 753, a length field 756, and one or more service grouping flooding options TLVs 759.

[00210] The type field 753 is a 16 bit field carrying a value indicating that the LSA 750 includes fields, such as the service grouping flooding options TLVs 759, which carries information related to service groups 130, verification criteria 222, and a negotiation policy 224.

In an embodiment, the type field 753 may be set to 1, or any other value that is assigned to represent LSAs 750 that carry information related to service groups 130, verification criteria 222, and the negotiation policy 224. The length field 756 is a 16 bit field indicating a length of the service grouping flooding options TL Vs 759.

[00211] The service grouping flooding options TLVs 759 includes a plurality of bits or fields that can indicate one or more service group IDs 140, the verification criteria 222 of the sending

NE 301-308, and a negotiation policy 224 associated with the service group 130. In an embodiment, the service grouping flooding options TLVs 759 may include a list of multiple service group-to-verification criteria-to-negotiation policy mappings. Each service group-to- verification criteria-to-negotiation policy mapping includes a mapping between a service group

ID 140, a verification criteria 222 for the service group 130 identified by the service group ID

140, and a negotiation policy 224 for the service group 130. That is, different service groups 130 have different service group IDs 140, and may also have different verification criteria 222. The verification criteria 222 may indicate one or more different path types used by the sending NE

301-308 to verify incoming second advertisements 637. Member NEs 301-306 in the same service group 130 may have the same negotiation policy 224. [00212] FIG. 8 is a schematic diagram illustrating network 800. Network 800 is similar to networks 300 of FIGS. 3, 4, and 6, except that service groups 130 are not provisioned in network

800. However, NEs 301-308 of network 800 are still configured to implement network connectivity verification according to various embodiments of the disclosure. As shown by FIG. 6, network 300 includes NEs 301-308 interconnected by links 323.

[00213] The first advertisement 827 A-H in FIG. 8 are similar to the first advertisement 627 described with reference to FIG. 6, which is flooded to all NEs 301-308 in the network 300.

However, unlike first advertisement 627, the first advertisement 827 A-H does not include a service group ID 130 or NE IDs 147A-N describing members NEs of a service group 130. Instead, the first advertisement 827A-H includes the verification criteria 222 for the NE 301-308 sending the first advertisement 827 A-H and the negotiation policy 224 for the NEs 301-308 in network 800.

[00214] In an embodiment, the verification criteria 222 and the negotiation policy 224 are determined by the central entity 103 and transmitted to at least one NE 301-308 in the network 300 via central entity-to-NE link 125. In another embodiment, an operator of network 300 preconfigures each of NEs 301-308 to verify incoming second advertisements 837 based on the verification criteria 222 and the negotiation policy 224.

[00215] As shown by FIG. 8, each NE 301-308 floods a first advertisement 827 A-H to all other

NEs 301-308 in the network 300. For example, NE 301 sends the first advertisement 827A to neighboring NEs 302 and 307. The first advertisement 827 A includes the verification criteria 222 indicating multiple path types that NE 301 uses to verify subsequently received second advertisements 837. The first advertisement 827A may also include a negotiation policy 224 indicating how to select a single path type from the multiple path types indicated by the verification criteria 222. NEs 302-306 may send similar first advertisements 827B-F. However, each of the first advertisements 827B-F includes the verification criteria 222 indicating multiple path types that the NE 302-306 sending the first advertisement 827B-F uses to verify subsequently received second advertisements 837. In an embodiment, NEs 302-306 may send similar first advertisements 827B-F with the same negotiation policy 224.

[00216] After NEs 301-308 have received and updated a local database to indicate the verification criteria 222 and negotiation policy 224 for all the other NEs 301-308 in the network

800, a second advertisement 837 may be sent in the network 800. The second advertisement 837 is similar to the second advertisement 137 of FIG. 1C, in that the second advertisement 837 does not include a service group ID 140. Instead, the second advertisement 837 includes the source NE ID

190 identifying an NE from which the second advertisement 837 originated.

[00217] In the example shown in FIG. 8, the second advertisement 837 originated from NE 302, and thus, the source NE ID 190 identifies source NE 302. When NE 304 receives the second advertisement 837, NE 304 verifies the second advertisement 837 based on a portion of a path 845 along which the second advertisement 837 was received, the source NE ID 190, and the topology of the network 800. NE 304 also verifies the second advertisement 837 based on the verification criteria 222 of NE 304 and the negotiation policy 224 of one or more NEs 301-308 in network 800, as described above with reference to FIGS. 4 and 6.

[00218] For example, NE 304’ s verification criteria 222 indicates that only second advertisements 837 received along shortest paths are verified. In the example shown in FIG. 8, NE

304 may verify the second advertisement 837 because the portion of the path 845 along which the second advertisement 837 was received is the shortest path between NEs 302 and 304.

[00219] As another example, suppose the second advertisement 837 included the source NE ID

190 identifying NE 307. The shortest path between NEs 307 and 304 is the single link 323 between NEs 307 and 304. In this example, when NE 304 receives the second advertisement 837 including the source NE ID 190 identifying NE 307 along the portion of the path 845, NE 304 determines that the second advertisement 837 was not received along the path indicated by the verification criteria 222. In this case, NE 304 may discard or drop the second advertisement 837 to ensure that the second advertisement 837 does not continue to be flooded through the network 800.

[00220] FIG. 9 is a flowchart illustrating a method 90 for implementing network connectivity verification according to various embodiments of the disclosure. Method 900 may be implemented by NEs 104-115, NE 200, or NEs 301-308 (hereinafter referred to as“NE”). Method 900 may be implemented after a first advertisement 127, 427, 627, or 827 (hereinafter referred to as“first advertisement”) has been flooded through the networks 100, 150, 175, 300, or 800 (hereinafter referred to as“network”) and programmed at each of the NEs in the network.

[00221] At step 903, the NE maintains a database indicating a topology of the network. In an embodiment, the database indicating a topology of the network is the LSDB 273, which is stored at memory 260. The topology of the network is stored at the LSDB 273 in response to receiving advertisements from other NEs in the network indicating link states and adjacencies between the other NEs in the network.

[00222] At step 906, the NE receives an advertisement from a neighboring NE. In an embodiment, this advertisement is the second advertisement 137, 437, 637, or 837, which is received after the first advertisement has been flooded through the network and programmed at each of the NEs in the network. This advertisement comprises the source NE ID 190. The source

NE ID 190 includes a label, address, or ID identifying a source NE from which the advertisement originated. [00223] At step 909, the NE determines whether the advertisement is valid based on a portion of the path along which the advertisement is received, the source NE ID 190, and the topology of the network. In an embodiment, the NE verifies the advertisement based on the verification criteria

222 of the NE, which indicates a path type used to verify incoming advertisements. In an embodiment, the NE selects the path type based on a negotiation policy 224 of the service group

130.

[00224] FIG. 10 is a flowchart illustrating a method 1000 for implementing network connectivity verification according to various embodiments of the disclosure. Method 1000 is implemented by NEs 104-115, NE 200, or NEs 301-308 (hereinafter referred to as“NE”). Method

1000 may be implemented after each of the NEs in the network have been programmed to maintain a topology of the network in, for example, an LSDB 273.

[00225] At step 1003, the NE obtains a first advertisement 127, 427, 627, or 827 indicating verification criteria 222 used by the NE to verify a second advertisement 137, 437, 637, or 837.

The first advertisement 127, 427, 627, or 827 may be received from another NE in the network, the central entity 103 in the network, or an operator of the network. Alternatively, the NE may generate the first advertisement 127, 427, or 627.

[00226] In an embodiment, the first advertisement comprises a service group ID 140, NE IDs

147 identifying NEs in the service group 130, and the verification criteria 222 for the service group

130. The verification criteria 222 indicates a path type used to verify the second advertisement

137, 437, or 637. The verification criteria 222 may include an encoding value representing a path type, such as, for example, a strict path, a best path, a matching best path, a backup path, a PPR, or a TE path. [00227] At step 1006, the NE transmits the first advertisement 127, 427, 627, or 827 to all neighboring NEs in the network. At step 1009, the NE receives the second advertisement 137,

437, 637, or 837 from a neighboring NE after obtaining the first advertisement 127, 427, 627, or

827. In an embodiment, the second advertisement 137, 437, 637, or 837 includes the source NE ID

190 identifying a source NE from which the second advertisement 137, 437, 637, or 837 originated. .

[00228] At step 1012, the NE verifies the second advertisement 137, 437, 637, or 837 based on the verification criteria 222, a portion of a path along which the second advertisement 137, 437,

637, or 837 is received, the source NE ID 190, and a topology of the network. The verification criteria 222 indicates a path type of a path, which is verified against the portion of the path along which the second advertisement 137, 437, 637, or 837 is received, to determine whether the second advertisement 137, 437, 637, or 837 is valid. In an embodiment, the NE determines a verified path between the source NE and the NE based on the path type indicated by the verification criteria 222.

The NE then determines whether the neighboring NE is on the verified path. If so, then the NE determines that the second advertisement 137, 437, 637, or 837 is valid and continues to flood the second advertisement 137, 437, 637, or 837 to other NEs in the service group 130. If not, then the

NE discontinues service group flooding of the second advertisement 137, 437, 637, or 837.

[00229] FIG. 11 is a schematic diagram illustrating an apparatus 1000 to implement network connectivity verification according to various embodiments of the disclosure. The apparatus 1000 includes a means for maintaining 1103, a means for receiving 1106, and a means for determining

1109. The means for maintaining 1103 comprises a means for maintaining a database indicating a topology of the network. The means for receiving 1106 comprises a means for receiving an advertisement from a neighboring NE, wherein the advertisement comprises the source NE ID 190. The means for determining 1109 comprises a means for verifying the advertisement based on a portion of a path along which the advertisement is received, the source NE ID 190, and the topology of the network.

[00230] FIG. 12 is a schematic diagram illustrating an apparatus 1100 to implement network connectivity verification according to various embodiments of the disclosure. The apparatus 1200 includes a means for obtaining 1203, a means for transmitting 1206, a means for receiving 1209, and a means for verifying 1212. The means for obtaining 1203 comprises a means for obtaining a first advertisement indicating verification criteria used by the NE to verify the advertisement, wherein the verification criteria indicates a path type used to verify a second advertisement. The means for transmitting 1206 comprises a means for transmitting the first advertisement to all neighboring NEs. The means for receiving 1209 comprises a means for receiving the second advertisement from a neighboring NE, wherein the second advertisement includes a source NE ID

190. The means for verifying 1212 comprises a means for verifying the second advertisement based on the verification criteria, the source NE ID 190, and a topology of the network.

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

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

Claims

CLAIMS What is claimed is:

1. A method performed by a network element (NE) in a network, comprising: maintaining a database indicating a topology of the network; receiving an advertisement from a neighboring NE, wherein the advertisement comprises a source NE identifier (ID) identifying a source NE from which the advertisement originated; and determining whether the advertisement is valid based on a portion of a path along which the advertisement is received, the source NE ID, and the topology of the network.

2. The method according to claim 1, wherein the neighboring NE and the NE are both members of a service group, and wherein the determining whether the advertisement is valid is also based on the NEs in the service group.

3 The method according to any one of claims 1 to 2, wherein determining whether the advertisement is valid comprises determining that the advertisement is valid, and wherein the method further comprises forwarding the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

4 The method according to claim 1, wherein the neighboring NE and the NE are not members of a common service group.

5. The method according to any one of claims 1 to 2 and 4, wherein determining whether the advertisement is valid comprises determining that the advertisement is invalid, and wherein the advertisement is not flooded to another neighbor of the NE in response to determining that the advertisement is invalid.

6. The method according to claim 1, wherein determining whether the advertisement is valid comprises:

determining that the portion of the path along which the advertisement is received is on a path from the source NE to the NE based on the topology of the network; and

determining that the advertisement is valid, and

wherein the method further comprises

forwarding the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

7. The method according to claim 1, wherein determining whether the advertisement is valid comprises:

determining that the portion of the path along which the advertisement is received is not on a path from the source NE to the NE based on the topology of the network; and

determining that the advertisement is invalid, wherein the advertisement is not flooded to another neighbor of the NE in response to the determining that the advertisement is invalid.

8. The method according to any one of claims 1 to 7, further comprising

transmitting a first advertisement including verification criteria to all neighboring NEs before receiving the advertisement from the neighboring NE, wherein the verification criteria indicates a path type used by the NE to verify a second advertisement, wherein determining whether the advertisement is valid comprises determining whether the advertisement is valid based on the verification criteria, the portion of the path along which the second advertisement is received, the source NE ID, and the topology of the network.

9. The method according to claim 8, wherein the path type indicated by the verification criteria includes at least one of a strict path, a shortest path, a matching best path, a backup path, a preferred path route (PPR), and a traffic-engineered (TE) path.

10. The method according to any one of claims 8 to 9, wherein determining whether the advertisement is valid comprises:

determining a path between the source NE and the NE based on the path type indicated by the verification criteria; and

determining whether the portion of the path along which the advertisement is received is on the path between the source NE and the NE, wherein the portion of the path along which the advertisement is received includes the neighboring NE.

11. The method according to claim 10, wherein determining whether the advertisement is valid comprises determining that the advertisement is invalid in response to determining that portion of the path along which the second advertisement is received is not on the path between the source

NE and the NE, wherein the advertisement is not flooded to another neighboring NE in response to determining that the advertisement is invalid.

12. The method according to claim 10, wherein determining whether the advertisement is valid comprises determining that the advertisement is valid in response to determining that the portion of the path along which the second advertisement is received is on the path between the source NE and the NE, and wherein the method further comprises forwarding the second advertisement to the next neighboring NE response to determining that the advertisement is valid.

13. The method according to any one of claims 8 to 12, wherein the first advertisement comprises the verification criteria and a negotiation policy, wherein the verification criteria indicates a first set of path types used to verify the advertisement received by the NE, wherein the first set of path types includes one or more path types, and wherein the negotiation policy indicates a manner by which to select a single path type for use by a plurality of NEs including the NE in verifying the second advertisement.

14. The method according to claim 13, further comprising:

receiving another first advertisement from a second NE, wherein the other first advertisement indicates the negotiation policy and a second set of path types used to verify subsequent advertisements received by the second NE, wherein the second set of path types includes one or more path types; and

determining the single path type from the first set of path types and the second set of path types based on the negotiation policy.

15. The method according to claim 14, wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type that is indicated in both the first set of path types and the second set of path types as the single path type.

16. The method according to claim 14, wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type as the single path type.

17. The method according to any one of claim 14, wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type defined by a central entity of the network as the single path type.

18. The method according to claim 14, wherein the first set of path types and the second set of path types do not include a matching path type, and wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type defined by a central entity of the network as the single path type.

19. The method according to claim 14, wherein the first set of path types and the second set of path types include at least two matching path types, and wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type or a path type defined by a central entity of the network as the single path type.

20. The method according to claim 14, wherein the first set of path types and the second set of path types include at least two matching path types, and wherein the negotiation policy indicates that a plurality ofNEs including the NE use a path type having a maximum or minimum encoding value as the single path type.

21. The method according to any one of claims 1 to 20, wherein the portion of the path along which the advertisement is received comprises a last portion of the path along which the advertisement is received.

22. The method according to claim 21, wherein the last portion of the path along which the advertisement is received comprises the neighboring NE.

23. A network element (NE), comprising:

a memory storing instructions; and

a processor coupled to the memory and configured to execute the instructions, which cause the processor to be configured to:

maintain a database indicating a topology of the network;

receive an advertisement from a neighboring NE, wherein the advertisement comprises a source NE identifier (ID) identifying a source NE from which the advertisement originated; and

determine whether the advertisement is valid based on a portion of a path along which the adverti sement is received, the source NE ID, an d the topol ogy of the network.

24. The apparatus according to claim 23, wherein the neighboring NE and the NE are both members of a service group, and wherein a determination of whether the advertisement is valid is also based on the NEs in the service group.

25. The apparatus according to any one of claims 23 to 24, wherein the instructions further cause the processor to:

determine that the advertisement is valid; and

forward the advertisement to the next neighboring NE in response to determining that the advertisement is valid.

26. The apparatus according to claim 23, wherein the neighboring NE and the NE are not members of a common service group, and wherein the instructions further cause the processor to be configured to determine that the advertisement is invalid, and wherein the advertisement is not flooded to another neighbor of the NE in response to determining that the advertisement is invalid.

27. The apparatus according to claim 23, wherein the instructions further cause the processor to be configured to:

determine that the portion of the path along which the advertisement is received is on a path from the source NE to the NE based on the topology of the network;

determine that the advertisement is valid; and

28. The apparatus according to claim 23, wherein the instructions further cause the processor to be configured to:

determine that the portion of the path along which the advertisement is received is not on a path from the source NE to the NE based on the topology of the network; and determine that the advertisement is invalid, wherein the advertisement is not flooded to another neighbor of the NE in response to the determining that the advertisement is invalid.

29. The apparatus according to any one claims 23 to 28, wherein the instructions further cause the processor to be configured to:

transmit a first advertisement including verification criteria to all neighboring NEs before receiving the advertisement from the neighboring NE, wherein the verification criteria indicates a path type used by the NE to verify a second advertisement; and

determine whether the advertisement is valid based on the verification criteria, the portion of the path along which the second advertisement is received, the source NE ID, and the topology of the network.

30. The apparatus according to claim 29, wherein the path type indicated by the verification criteria includes at least one of a strict path, a shortest path, a matching best path, a backup path, a preferred path route (PPR), and a traffic-engineered (TE) path.

31. The apparatus according to any one of claims 29 to 30, wherein the instructions further cause the processor to be configured to:

determine a path between the source NE and the NE based on the path type indicated by the verification criteria; and

determine whether the portion of the path along which the advertisement is received is on the path between the source NE and the NE, wherein the portion of the path along which the advertisement is received includes the neighboring NE.

32. The apparatus according to claim 31, wherein the instructions further cause the processor to be configured to determine that the advertisement is invalid in response to determining that portion of the path along which the second advertisement is received is not on the path between the source

33. The apparatus according to claim 31, wherein the instructions further cause the processor to be configured to determine that the advertisement is valid in response to determining that the portion of the path along which the second advertisement is received is on the path between the source NE and the NE, and wherein the method further comprises forwarding the second advertisement to the next neighboring NE response to determining that the advertisement is valid.

34. The apparatus according to any one of claims 29 to 33, wherein the first advertisement comprises the verification criteria and a negotiation policy, wherein the verification criteria indicates a first set of path types used to verify the advertisement received by the NE, wherein the first set of path types includes one or more path types, and wherein the negotiation policy indicates a manner by which to select a single path type for use by a plurality of NEs including the NE in verifying the second advertisement.

35. The apparatus according to claim 34, wherein the instructions further cause the processor to be configured to:

receive another first advertisement from a second NE, wherein the other first advertisement indicates the negotiation policy and a second set of path types used to verify subsequent advertisements received by the second NE, wherein the second set of path types includes one or more path types; and

determine the single path type from the first set of path types and the second set of path types based on the negotiation policy.

36. The apparatus according to claim 35, wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type that is indicated in both the first set of path types and the second set of path types as the single path type.

37. The apparatus according to claim 35, wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type as the single path type.

38. The apparatus according to claim 35, wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type defined by a central entity of the network as the single path type.

39. The apparatus according to any one of claims 23 to 38, wherein the portion of the path along which the advertisement is received comprises a last portion of the path along which the advertisement is received, and wherein the last portion of the path along which the adverti sement is received comprises the neighboring NE.

40. A non-transitory computer-readable medium configured to store a computer program product comprising computer executable instructions that, when executed by a processor of a network element (NE) implemented in a network, cause the processor to be configured to:

maintain a database indicating a topology of the network;

receive an advertisement from a neighboring NE, wherein the advertisement comprises a source NE identifier (ID) identifying a source NE from which the advertisement originated; and determine whether the advertisement is valid based on a portion of a path along which the advertisement is received, the source NE ID, and the topology of the network.

41. The non-transitory computer-readable medium according to claim 40, wherein the neighboring NE and the NE are both members of a service group, and wherein a determination of whether the advertisement is valid is also based on the NEs in the service group.

42. The non-transitory computer-readable medium according to any one of claims 40 to 41, wherein the computer executable instructions further cause the processor to be configured to:

determine that the advertisement is valid; and

43. The non-transitory computer-readable medium according to claim 40, wherein the neighboring NE and the NE are not members of a common service group, and wherein the computer executable instructions further cause the processor to be configured to determine that the advertisement is invalid, and wherein the advertisement is not flooded to another neighbor of the

NE in response to determining that the advertisement is invalid.

44. The non-transitory computer-readable medium according to claim 40, wherein the computer executable instructions further cause the processor to be configured to:

determine that the advertisement is valid; and

45. The non-transitory computer-readable medium according to claim 40, wherein the computer executable instructions further cause the processor to be configured to:

determine that the portion of the path along which the advertisement is received is not on a path from the source NE to the NE based on the topology of the network; and

determine that the advertisement is invalid, wherein the advertisement is not flooded to another neighbor of the NE in response to the determining that the advertisement is invalid.

46. The non-transitory computer-readable medium according to any one claims 40 to 45, wherein the computer executable instructions further cause the processor to be configured to:

transmit a first advertisement including verification criteria to all neighboring NEs before receiving the advertisement from the neighboring NE, wherein the verification criteria indicates a path type used by the NE to verify a second advertisement; and determine whether the advertisement is valid based on the verification criteria, the portion of the path along which the second advertisement is received, the source NE ID, and the topology of the network.

47. The non-transitory computer-readable medium according to claim 46, wherein the path type indicated by the verification criteria includes at least one of a strict path, a shortest path, a matching best path, a backup path, a preferred path route (PPR), and a traffic-engineered (TE) path.

48. The non-transitory computer-readable medium according to any one of claims 46 to 47, wherein the computer executable instructions further cause the processor to be configured to:

49. The non-transitory computer-readable medium according to claim 48, wherein the computer executable instructions further cause the processor to be configured to determine that the advertisement is invalid in response to determining that portion of the path along which the second advertisement is received is not on the path between the source NE and the NE, wherein the advertisement is not flooded to another neighboring NE in response to determining that the advertisement is invalid.

50. The non-transitory computer-readable medium according to claim 48, wherein the computer executable instructions further cause the processor to be configured to determine that the advertisement is valid in response to determining that the portion of the path along which the second advertisement is received is on the path between the source ME and the ME, and wherein the method further comprises forwarding the second advertisement to the next neighboring NE response to determining that the advertisement is valid.

51. The non-transitory computer-readable medium according to any one of claims 46 to 50, wherein the first advertisement comprises the verification criteria and a negotiation policy, wherein the verification criteria indicates a first set of path types used to verify the advertisement received by the NE, wherein the first set of path types includes one or more path types, and wherein the negotiation policy indicates a manner by which to select a single path type for use by a plurality of

NEs including the NE in verifying the second advertisement.

52. The non-transitory computer-readable medium according to claim 51, wherein the computer executable instructions further cause the processor to be configured to:

53. The non-transitory computer-readable medium according to claim 51, wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type that is indicated in both the first set of path types and the second set of path types as the single path type.

54. The non-transitory computer-readable medium according to claim 51, wherein the negotiation policy indicates that a plurality of NEs including the NE use a default path type as the single path type.

55. The non-transitory computer-readable medium according to claim 51, wherein the negotiation policy indicates that a plurality of NEs including the NE use a path type defined by a central entity of the network as the single path type.

56. The non-transitory computer-readable medium according to any one of claims 40 to 56, wherein the portion of the path along which the advertisement is received comprises a last portion of the path along which the advertisement is received, and wherein the last portion of the path along which the advertisement is received comprises the neighboring NE.