WO2020231740A1

WO2020231740A1 - Open shortest path first (ospf) service grouping capability, membership, and flooding

Info

Publication number: WO2020231740A1
Application number: PCT/US2020/031878
Authority: WO
Inventors: Padmadevi Pillay-Esnault; Uma S. Chunduri; Alvaro Retana
Original assignee: Futurewei Technologies, Inc.
Priority date: 2019-05-10
Filing date: 2020-05-07
Publication date: 2020-11-19

Abstract

A method performed by a network element (NE) in a network implementing Open Shortest Path First (OSPF), comprising transmitting, to a neighboring (N)E, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group, receiving, from the neighboring (NE), a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group, and determining that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

Description

Open Shortest Path First (OSPF) Service Grouping Capability, Membership, and Flooding CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of U.S. Provisional Patent Application No. 62/846,054 filed May 10, 2019 by Padmadevi Pillay-Esnault, el. al ., and entitled“OSPF SERVICE GROUPING CAPABILITY, MEMBERSHIP AND FLOODING,” and U.S. Provisional Patent Application No. 62/846,784 filed May 13, 2019 by Padmadevi Pillay-Esnault, el. al., and entitled “OSPF: USING SERVICE GROUPINGS FOR PPR PATHS,” which are 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 efficient 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 implementing OSPF, comprising transmitting, to a neighboring NE, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group, receiving, from the neighboring NE, a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group, and determining that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

[0008] Optionally, in a first implementation according to the first aspect, before transmitting the first advertisement to the neighboring NE, the method further comprises receiving an advertisement comprising the service group ID from a central entity of the network or another NE in the network.

[0009] Optionally, in a second implementation according to the first aspect or any other implementation of the first aspect, before transmitting the first advertisement to the neighboring NE, the method further comprises generating the first advertisement

[0010] Optionally, in a third implementation according to the first aspect or any other implementation of the first aspect, the first advertisement comprises a first flag indicating that the NE is capable of implementing service group forwarding, and wherein the second advertisement comprises a second flag indicating that the neighboring NE is capable of implementing service group forwarding.

[0011] Optionally, in a fourth implementation according to the first aspect or any other implementation of the first aspect, the first advertisement comprises a plurality of service group IDs identifying a plurality of service groups, wherein the NE is a member of each of the plurality of service groups.

[0012] Optionally, in a fifth implementation according to the first aspect or any other implementation of the first aspect, the first advertisement comprises the service group ID and a plurality of IDs identifying each of the NEs that are members of the service group.

[0013] Optionally, in a sixth implementation according to the first aspect or any other implementation of the first aspect, the service group is a member of a service group set comprising a plurality of service groups, wherein a service group set ID identifies the service group set, wherein the first advertisement comprises the service group set ID, and wherein the second advertisement comprises the service group set ID.

[0014] Optionally, in a seventh implementation according to the first aspect or any other implementation of the first aspect, the service group set is associated with a service

[0015] According to a first aspect of the present disclosure, there is provided a method performed by an NE in a network implementing OSPF, comprising receiving an advertisement comprising a service group identifier (ID) indicating a service group including the NE, determining all neighboring NEs that are members of the service group identified by the service group ID, and flooding the advertisement to all the neighboring NEs based on the service group ID.

[0016] Optionally, in a first implementation according to the second aspect, the NE is adjacent to a plurality of neighboring NEs, wherein all neighboring NEs that are members of the service group include at least one of the plurality of neighboring NEs

[0017] Optionally, in a second implementation according to the second aspect or any other implementation of the second aspect, the service group ID is 0, and wherein the method further comprises forwarding the advertisement to all neighboring NEs of the NE . [0018] Optionally, in a third implementation according to the second aspect or any other implementation of the second aspect, the method further comprising updating a database stored locally at the NE to include data from the advertisement

[0019] According to a third aspect of the present disclosure, there is provided a NE in a network implementing OSPF, comprising a memory storing instructions, a processor configured to execute the instructions, which cause the processor to be configured to transmit, to a neighboring NE, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group, receive, from the neighboring NE, a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group determine that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

[0020] Optionally, in a first implementation according to the third aspect, before the first advertisement is transmitted to the neighboring NE, the instructions further cause the processor to receive an advertisement comprising the service group ID from a central entity of the network or another NE in the network.

[0021] Optionally, in a second implementation according to the third aspect or any other implementation of the third aspect, before the first advertisement is transmitted to the neighboring NE, the instructions further cause the processor to generate the first advertisement.

[0022] Optionally, in a third implementation according to the third aspect or any other implementation of the third aspect, the first advertisement comprises a first flag indicating that the NE is capable of implementing service group forwarding, and wherein the second advertisement comprises a second flag indicating that the neighboring NE is capable of implementing service group forwarding. [0023] Optionally, in a fourth implementation according to the third aspect or any other implementation of the third aspect, the first advertisement comprises a plurality of service group IDs identifying a plurality of service groups, wherein the NE is a member of each of the plurality of service groups.

[0024] Optionally, in a fifth implementation according to the third aspect or any other implementation of the third aspect, the first advertisement comprises the service group ID and a plurality of IDs identifying each of the NEs that are members of the service group.

[0025] According to a fourth aspect of the present disclosure, there is provided a NE in a network implementing OSPF, comprising a memory storing instructions, a processor configured to execute the instructions, which cause the processor to be configured to receive an advertisement comprising a service group identifier (ID) indicating a service group including the NE, determine all neighboring NEs that are members of the service group identified by the service group ID, flood the advertisement to all the neighboring NEs based on the service group ID.

[0026] Optionally, in a first implementation according to the fourth aspect, the NE is adjacent to a plurality of neighboring NEs, wherein all neighboring NEs that are members of the service group include at least one of the plurality of neighboring NEs.

[0027] Optionally, in a second implementation according to the fourth aspect or any other implementation of the fourth aspect, the service group ID is 0, and wherein the method further comprises forwarding the advertisement to all neighboring NEs of the NE.

[0028] Optionally, in a third implementation according to the fourth aspect or any other implementation of the fourth aspect, the instructions further cause the processor to be configured to update a database stored locally at the NE to include data from the advertisement. [0029] According to a fifth aspect of the present disclosure, there is provided an apparatus comprising a means for transmitting, to a neighboring NE, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group, a means for receiving, from the neighboring NE, a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group, and a means for determining that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

[0030] According to a sixth aspect of the present disclosure, there is provided an apparatus comprising a means for receiving an advertisement comprising a service group identifier (ID) indicating a service group including the NE, a means for determining all neighboring NEs that are members of the service group identified by the service group ID, and a means for flooding the advertisement to all the neighboring NEs based on the service group ID.

[0031] 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.

[0032] 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

[0033] 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. [0034] FIG. 1 A is a schematic diagram illustrating a network configured to implement service groups using an OSPF protocol according to various embodiments of the disclosure.

[0035] FIG. IB is a schematic diagram illustrating another network configured to implement service groups using an OSPF protocol according to various embodiments of the disclosure

[0036] FIG. 2 is a schematic diagram of an NE suitable to implement service groups using an OSPF protocol according to various embodiments of the disclosure.

[0037] FIGS. 3A-B are schematic diagrams illustrating examples of an advertisement that is flooded through the network of FIG. 1 A according to a first embodiment of the disclosure.

[0038] FIGS. 4A-B are schematic diagrams illustrating examples of another advertisement that is flooded through the network of FIG. IB according to a second embodiment of the disclosure,

[0039] FIG. 5 is a schematic diagram illustrating another network configured to implement service groups using an OSPF protocol according to various embodiments of the disclosure.

[0040] FIG. 6 is a schematic diagram illustrating the flooding of data to service group neighbors in the network of FIG. 5 according to various embodiments of the disclosure.

[0041] FIG. 7A is a schematic diagram illustrating the provisioning of PPRs in a network using service groups according to various embodiments of the disclosure.

[0042] FIG. 7B is a schematic diagram illustrating the provisioning of loose PPRs in a network using service groups according to various embodiments of the disclosure.

[0043] FIG. 8 is a flowchart illustrating a method for implementing service groups in the control plane according to various embodiments of the disclosure.

[0044] FIG. 9 is a flowchart illustrating a method for implementing service groups in the flooding plane according to various embodiments of the disclosure. [0045] FIG. 10 is a schematic diagram illustrating an apparatus to implement service groups in the control plane according to various embodiments of the disclosure.

[0046] FIG. 11 is a schematic diagram illustrating an apparatus to implement service groups in the flooding plane according to various embodiments of the disclosure.

DETAILED DESCRIPTION

[0047] 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.

[0048] FIG. 1A is a schematic diagram illustrating a network 100 (also referred to herein as an “autonomous system (AS)” or“domain”) configured to implement service groups 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 “OSFP”) 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 100 comprises a central entity 103 (also referred to herein as a“controller”) and multiple NEs 104-112. In the embodiment shown in FIG. 1 A, the central entity 103 is coupled to each of the NEs 104-112 via the central entity -to-NE links 125. The NEs 104-112 are interconnected by links 123. [0049] 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.

[0050] NEs 104-112 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-112 are headend nodes or edge nodes positioned at an edge of the network 100. For example, one or more of NEs 104-112 may be an ingress node at which traffic (e.g., control packets and data packets) is received, and one or more of NEs 104-112 may be an egress node from which traffic is transmitted. Some of the NEs 104-112, such as NEs 108 and 107, may be interior nodes that are configured to receive and forward traffic from another NE 104-112 in the network 100. [0051] The central entity-to-NE links 125 may be wired links, wireless links, or interfaces interconnecting each of the NEs 104-112 with the central entity 103. Similarly, the links 123 may be wired links, wireless links, or interfaces interconnecting each of the NEs 104-112.

[0052] Although only nine NEs 104-112 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 nine, more than nine, or more than 100. In an embodiment, the central entity 103 and NEs 104-112 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.

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

[0054] To flood the network 100, each NE 104-112 forwards an advertisement 165 including the information to neighboring NEs 104-112 in the network 100. As used herein, neighboring NEs 104-112 refers to two adjacent NEs each having interfaces that can directly communicate one with one another.

[0055] In an example in which an advertisement 165 is flooded through the network 100, NE

105 transmits an advertisement 165 to neighboring NEs 104 and 106. The receiving NEs 104 and

106 each update a local database to include the information in the advertisement 165. Each of the receiving NEs 104 and 106 then forwards the advertisement 165 to neighboring NEs. That is, NE 104 forwards the advertisement 165 to NE 109, and NE 106 forwards the advertisement 165 to NEs 107 and 112. NEs 109, 107, and 112 similarly update their local database and forward the advertisement 165 to neighboring NEs 110, 109, and 111.

[0056] Each of the NEs 104-112 forward the advertisement 165 in a single direction, and do not forward the advertisement 165 back to an NE 104-112 from which the advertisement 165 may have been received. For example, NE 104 receives the advertisement 165 from NE 105 and forwards the advertisement 165 to NE 109, but does not forward the advertisement 165 back to NE 105, from which the advertisement 165 was received.

[0057] The advertisements 165 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-112. 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 2740, entitled“OSPF for IPv6,” dated July 2008, by R. Colton, et. al, which is incorporated by reference herein in its entirety.

[0058] 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 165 may be stored in the LSDB of each NE 104-112. Each NE 104-112 may use the information stored in the LSDB to obtain a topology of the network 100. [0059] 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-112 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.

[0060] To provision a shortest path across the network 100, each NE 104-112 constructs a shortest path tree to each destination in the network 100, and uses this shortest path tree to construct a routing table describing the path to each destination in the network. For example, a shortest path tree may be computed for a destination using a Dijkstra’s Shortest Path First (SPF) algorithm. Each NE 104-112 may determine the shortest path to a destination in the network 100 based on the costs of each of the links 123 interconnecting NEs 104-112 in the network 100.

[0061] 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 or between a source and destination. A PPR may also be the same as the shortest path. The PPRs are determined based on an application or server request for a path between two NEs 104-112 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 Application No. PCT/US2018/015419, filed on January 28, 2019, which is incorporated by reference herein in its entirety.

[0062] To provision a PPR, the central entity 103 is configured to determine one or PPRs between the two NEs 104-112 of the network 100 using a network topology of the network 100. The central entity 103 may determine the PPR based on capabilities of NEs 104-112 within network 100 and based on an application or server request for a PPR. In one case, the central entity 103 transmits an advertisement 165 including PPR information describing the determined PPR to at least one NE 104-112 in the network 100. The PPR information includes a PPR- identifier (ID) identifying the PPR, and multiple PPR path description elements (PPR-PDEs). Each PPR-PDE is a label, address, or ID identifying an NE 104-112 or a link 123 along the PPR.

[0063] A PPR graph refers to a collection of multiple PPRs between one or more ingress NEs 104-112 (also referred to herein as“sources”) and one or more egress NEs 104-112 (also referred to herein as“destinations”). A PPR graph may include a single source and multiple destinations, multiple destinations and a single source, or multiples sources and multiple destinations. PPR graphs are further defined in International Application No. PCT/US2019/030440, filed on May 2, 2019, which is incorporated by reference herein in its entirety.

[0064] To provision a PPR graph, the central entity 103 is configured to determine a PPR graph between one or more ingress NEs 104-112 and one or more egress NEs 104-112 using a network topology of the network 100. The central entity 103 may also determine the PPR graph based on capabilities of NEs 104-112 within network 100 and based on an application or server request for a PPR graph. In this case, the central entity 103 transmits an advertisement 165 including PPR information describing the determined PPR graph to at least one NE 104-112 in the network 100. The PPR information includes a PPR graph ID identifying the PPR, and multiple PPR-PDEs. Each PPR-PDE identifies an NE 104-112 or a link 123 along the PPR graph.

[0065] 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 165 may be stored in the routing table of each NE 104-112. Each NE 104-112 uses the routing table to determine next hops by which to forward advertisements 165 or other types of OSPF packets. [0066] In some cases, the advertisements may also contain any information related to a service or application that uses one or more NEs 104-112 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.

[0067] Whether an NE 104-112 receives an advertisement or generates an advertisement, NE 104-112 is configured to initiate OSPF flooding of the advertisement through the network 100. For example, after obtaining an advertisement 165, NE 109 is configured to update a local database with information from the advertisement 165, and then forward the advertisement 165 to neighboring NEs 104, 108, and 110. Upon receiving the advertisement 165, NEs 104, 108, and 110 also update their local databases and then forward the advertisement 165 to neighboring NEs 105, 107, and 111. That is, NE 104 forwards the advertisement 165 to NE 105, NE 108 forwards the advertisement 165 to NE 107, and NE 110 forwards the advertisement 165 to NE 111. Similarly, upon receiving the advertisement 165, NEs 105, 107, and 111 are configured to update their local databases and forward the advertisement 165 to neighboring NEs 106 and 112. In this manner, the OSPF protocol allows networks 100 to implement a reliable flooding mechanism by which all the NEs 104-112 in the network 100 maintain an identical and synchronized view of the network 100.

[0068] However in some cases, the information that is flooded through the network 100 is completely irrelevant to some of the NEs 104-112 that receive the information. In these cases, each of the NEs 104-112 nevertheless process and store this information even though the NEs 104- 112 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.

[0069] Disclosed herein are embodiments directed to an enhanced OSPF protocol directed to reducing the amount of information flooded through the network 100 by provisioning service groups 130A-B within a network 100 and 150. In an embodiment, a service group 130A-B includes one or more NEs 104-112 in a network 100, or area, that are associated with an application or a service. An NE 104-112 may belong to zero or more service groups 130A-B.

[0070] As shown in FIG. 1A, the service group 130A includes NEs 104, 108, 109, 110, and 111. Service group 130B includes NEs 105, 106, 107, and 112. Service group 130A may be associated with a first service, and service group 130B may be associated with a second 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 130A-B may be identified by a service group ID 140.

[0071] Service groups 130A and 130B may be grouped together in a service group set 135. A service group set 135 may be identified by a service group set ID 145. The service group set ID 145 identifies the service group set 135 to which the service groups 130A-130B belong. While the service group set 135 in FIG. 1A includes two service groups (e.g., service groups 130A-130B), the service group set 135 may include a different number of service groups in practical applications. In an embodiment, each service group set 135 includes at least two service groups

130A-B. [0072] In an embodiment, the central entity 103 stores a database including service group mappings between applications/services and service groups 130A-B. The service group mappings include mappings between applications/services, the service group set 135, service groups 130A-B in the service group set 135, and NEs 104-112 in each of the service groups 130A-B. For example, a mapping for one or more applications or services may include one or more service group IDs 140 and one or more labels, addresses, or IDs of the NEs 104-112 in the corresponding service group 130A-B. The mapping may also include a service group set ID 145 when the service groups 130A-B are part of a service group set 135. In this embodiment, the central entity 103 has knowledge of the service groups 130A-B and the service group set 135 in which each of the NEs 104-112 belongs.

[0073] In the control plane, the central entity 103 may transmit service group capability information 160 to each of the NEs 104-112 in the network 100 via the central entity -to-NE links 125. In this embodiment shown in FIG. 1A, the service group capability information 160 includes the service group IDs 140 that indicate which service group 130A-B each of the receiving NEs 104-112 belongs to. The service group capability information 160 may also include a service group set ID 145 that indicates which service group set each of the receiving NEs 104-112 belongs to. For example, the central entity 103 sends the service group capability information 160, which includes a service group ID 140 for service group 130A, to NE 109 via central entity-to-NE link 125. Similarly, the central entity 103 sends the service group capability information 160, which includes a service group ID 140 for service group 130A, to NEs 104, 108, 110, and 111 via central entity-to-NE links 125. The central entity 103 also sends service group capability information 160, which includes a service group ID 140 for service group 130B, to NEs 105, 106, 107, and 112 via central entity-to-NE links 125. [0074] Upon receiving the service group capability information 160, each of the NEs 104-112 floods the network 100 with an advertisement 165 including the service group capability information 160 related to the respective NE 104-112. In an embodiment, the advertisement 165 includes one or more service group IDs 140 that indicate which service group each of the sending NEs 104-112 belongs to. In an embodiment, the advertisement 165 also includes a capability flag set to indicate whether the NEs 104-112 are capable of implementing service groups 130A-B and service group flooding.

[0075] For example, after NE 109 receives the service group capability information 160 from the central entity 103, NE 109 initiates flooding of an advertisement 165 through the network 100. The advertisement 165 includes a service group ID 140 and a capability flag indicating that NE 109 is capable of implementing service groups 130A-B and service group flooding. The advertisement 165 may also include the service group set ID 145 identifying the service group set 135. The advertisement 165 indicates that NE 109 is a member of the service group 130A identified by the service group ID 140. When the service group set ID 145 is included in the advertisement 165, the advertisement 165 indicates that NE 109 is also a member of the service group set 135. NE 109 transmits the advertisement 165 to NEs 104, 108, and 110. NEs 104, 108, and 110 each update a local database, such as the LSDB, to indicate the service group ID 140 and service group set ID 145 associated with NE 109. NEs 104, 109, and 110 continue to forward the advertisement 165 to neighboring NEs 105, 107, and 111. NEs 105, 107, and 111 each update a local database, such as the LSDB, to indicate the service group ID 140 and service group set ID 145 associated with NE 109. NEs 105, 107, and 111 continue to forward the advertisement 165 to neighboring NEs 106 and 112. NEs 106 and 112 each update a local database, such as the LSDB, to indicate the service group ID 140 and service group set ID 145 associated with NE 109 (e.g., the sending NE). NEs 106 and 112 do not have any other neighboring NEs, other than the NEs 105, 107, and 111 from which the advertisement 165 was received. Therefore, NEs 106 and 112 terminate or discontinue transmission of the advertisement 165.

[0076] Similarly, each of the other NEs 104-108 and 110-112 in the network 100 create an advertisement 165 including a capability flag and one or more service group IDs 140 identifying service groups 130A-B to which the respective NEs 104-108 and 110-112 belong. The NEs 104- 108 and 110-112 flood the network 100 with the advertisement 165 similar to that described above with respect to NE 109. After each of the NEs 104-112 have flooded the network 100 with the advertisement 165 including the service group capability information 160 for each of the NEs 104- 112 and each of the NEs 104-112 have updated the local database to reflect the service groups 130A-B and the service group set 135 within the network 100, each of the NEs 104-112 maintains an identical view of the service groups 130A-B and service group set 135 provisioned in the network 100.

[0077] NEs 104-112 use the local database to determine neighboring NEs 104-112 that are members of the same service group 130A-B and/or service group set 135. For example, NE 109 uses the local database to determine that NEs 104, 108, and 110 are also members of service group 130A. Similarly, NE 104 uses the local database to determine that neighboring NE 109 is a member of service group 130A, but neighboring NE 105 is not a member of service group 130A. NEs 105-108 and 110-114 perform similar determinations to determine neighboring NEs 104-112 that are members of the same service group 130A-B and/or the service group set 135.

[0078] In the flooding plane, which will be illustrated in more detail below with reference to FIG. 6, the NEs 104-112 forward subsequent advertisements (i.e., advertisements received after the advertisement 165) according to the service group ID 140. That is, subsequent advertisements including a service group ID 140 associated with a service group 130A-B are only forwarded to neighboring NEs that have the same service group ID 140 and are therefore members of the same service group 130A-B. The NEs 104-112 also forward subsequent advertisements according to a service group set ID 145 associated with a service group set 135. That is, subsequent advertisements including the service group set ID 145 are only forwarded to neighboring NEs that are members of the same service group set 135. Embodiments directed to the flooding plane will be further discussed below with reference to FIG. 6.

[0079] While FIG. 1A shows the central entity 103 programming each of the NEs 104-112 with the service group capability information 160, in another embodiment, an operator of the network 100 may preconfigure each of the NEs 104-112 with the group capability information 160 for the respective NE 104-112. The operator of the network 100 may also store the service group capability information 160 at the central entity 103. In this embodiment, the central entity 103 need not forward the service group capability information 160 to each of the NEs 104-112.

[0080] FIG. IB is a schematic diagram illustrating a network 150 configured to implement service groups 130A-B using an OSPF protocol according to various embodiments of the disclosure. Similar to network 100 of FIG. 1A, network 150 comprises a central entity 103 and multiple NEs 104-112, As shown, the NEs 104-112 are interconnected by links 123.

[0081] Unlike network 100 of FIG. 1A, the central entity 103 in FIG. IB is coupled to only one of the NEs 109 in the network 150 via central entity-to-NE link 125. In FIG. 1A, the central entity 103 separately sends service group capability information 160 to each of the NEs 104-112 in the network 100, That service group capability information 160 only indicates the service groups 130A-B to which the receiving NE 104-112 belongs. In contrast, FIG. IB shows that the central entity 103 sends service group capability information 180 to a single NE 109 in the network 150. That service group capability information 180 indicates the service groups 130A-B to which all the NEs 104-112 in the network 150 belong.

[0082] In this embodiment, the service group capability information 180 includes a service group ID 140 for each of the service groups 130A-B in the network, and NE IDs 147 for each of the NEs 104-112 that are members of each of the service groups 130A-B. The NE IDs 147 include labels, addresses, or IDs identifying or describing the NEs 104-112 in the corresponding service group 130A-B. The service group capability information 180 may also include a service group set ID 145 identifying a service group set 135 to which the service groups 130A-B belong.

[0083] For example, NE 109 receives the service group capability information 180 from the central entity 103 and updates the local database (e.g., LSDB) to include entries indicating the service group set 135, service groups 130A-B, and member NEs 104-112 in the network 150. NE 109 then initiates flooding of the advertisement 185 including the service group capability information 180 to the rest of the NEs 104-112. NE 109 transmits the advertisement 185 to neighboring NEs 104, 108, and 110. NEs 104, 108, and 110 update their local databases to include the service group capability information 180 and forward the advertisement 185 to neighboring NEs 105, 107, and 111. NEs 105, 107, and 111 update their local databases to include the service group capability information 180 and forward the advertisement 185 to neighboring NEs 106 and 112. NEs 106 and 112 terminate or discontinue the flooding of the advertisement 185.

[0084] NEs 104-112 use the local database to determine neighboring NEs 104-112 that are members of the same service group 130A-B. For example, NE 109 uses the local database to determine that NEs 104, 108, and 110 are also members of service group 130A. Similarly, NE 104 uses the local database to determine that neighboring NE 109 is a member of service group 130A, but neighboring NE 105 is not a member of service group 130A. [0085] FIG. 2 is a schematic diagram of an NE 200 suitable to implement service groups 130A-B according to various embodiments of the disclosure. In an embodiment, the NE 200 may be implemented as any one of NEs 104-112 or the central entity 103.

[0086] The NE 200 comprises ports 220, transceiver units (Tx/Rx) 210, a processor 230, and a memory 260. The processor 230 comprises a path aware 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.

[0087] 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 to forward advertisements 165 and 185 to only the NEs 104-112 in a service group 130A-B identified in the advertisements 165 and 185. 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.

[0088] 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).

[0089] 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 neighbors 280, LSDB 273 (shown in FIG. 2 as the“link-state database 273”), routing table 276, and service group mappings 279. The service group capability information 265 is similar to the service group capability information 160 of FIG. 1A and the service group capability information 180 of FIG. IB. The service group ID 140 is a value uniquely identifying a service group 130A-B.

[0090] A service group set 135 includes one or more service groups 130A-B. A service group set ID 145 is a value uniquely identifying a service group set 135. A service group neighbor 280 refers to one or more NEs 104-112 that neighbor a respective NE 104-112 and is a member of a common service group 130A-B. The LSDB 273 stores information describing a topology of network 100 or 150. The routing table 276 includes routing information describing a next hop to every destination in the network 100 or 150 from the NE 200.

[0091] The service group mappings 279 may include mappings between an application or service 277, zero or more service group set IDs 145 (shown in FIG. 2 as“SGS ID 145”), 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.

[0092] 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.

[0093] FIGS. 3A-B are schematic diagrams illustrating examples of the advertisement 165 according to a first embodiment of the disclosure. Specifically, FIG. 3A is a schematic diagram illustrating data included within the advertisement 165 flooded through network 100 of FIG. 1A, and FIG. 3B is a schematic diagram illustrating the advertisement 165 encoded as a portion of an LSA 350. As described above with reference to FIG. 1A, the NEs 104-112 flood the network 100 with the advertisement 165 after receiving service group capability information 160 from the central entity 103.

[0094] Referring now to FIG. 3A, the advertisement 165 comprises a capability flag 303, one or more service group IDs 140A-N, and one or more service group set IDs 145A-N. In an embodiment, the capability flag 303 is a flag, or a bit, that is set to indicate that an NE 104-112 sending the advertisement 165 (e.g., sending NE 104-112) is capable of implementing service groups 130A-B (referred to hereinafter as“service groups 130”) and flooding the network 100 based on the service groups 130. The service group IDs 140A-N include one or more service group IDs 140A-N identifying service groups 130 to which the sending NE 104-112 belongs. In an embodiment, the service group IDs 140A-N are values uniquely identifying a service group 130. The service group ID 140A-N 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 145A-N include one or more service group set IDs 145A-N identifying service group set 135 to which the sending NE 104-112 belongs. The service group set ID 145A-N may also 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 advertisement 165 may not necessarily include the service group set IDs 145A-N if the sending NE 104-112 is not a member of a service group 130 that is also part of a service group set 135

[0095] Referring now to FIG. 3B, shown is a portion of the LSA 350 (which is referred to herein as the LSA). The LSA 350 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 herein in its entirety. It should be appreciated that LSA 350 may otherwise be any other type of LSA as defined for the OSPF protocol.

[0096] The LSA 350 shown in FIG. 3B is a type-length-value (TLV) included within the body of the RI opaque LSA. The LSA 350 includes a type field 353, a length field 356, an informational capabilities field 359, and a service grouping TLV 370.

[0097] The type field 353 is a 16 bit field carrying a value indicating that the LSA 350 includes fields, such as the informational capabilities field 359, which carries information related to service groups 130. In an embodiment, the type field 353 may be set to 1, or any other value that is assigned to represent LSAs 350 that carry information related to service groups 130. The length field 356 is a 16 bit field indicating a length of the informational capabilities field 359.

[0098] The informational capabilities field 359 includes a plurality of bits or flags that have been assigned for various purposes. Currently bits 6-31 are unassigned. In an embodiment, one of these bits may be the capability flag 303 of FIG. 3 A. For example, bit 7 in the informational capabilities field 359 may be the capabilities flag 303.

[0099] The service grouping TLV 370 includes a type field 362, a length field 365, and a service grouping field 366. In this embodiment, the type field 362 is a 16 bit field carrying a value indicating that the LSA 350 includes fields, such as the service grouping field 366, which carries information related to service groups 130. In an embodiment, the type field 362 may be set to 1 , or any other value that is assigned to represent LSAs 350 that carry information related to service groups 130. The length field 365 is a 16 bit field indicating a length of the service grouping field 366. The service grouping field 366 indicates the service group IDs 140A-N and/or the service group set IDs 145A-N.

[00100] FIGS. 4A-B are schematic diagrams illustrating examples of the advertisement 185 according to a first embodiment of the disclosure. Specifically, FIG. 4A is a schematic diagram illustrating data included within the advertisement 185 flooded through network 150 of FIG. IB, and FIG. 4B is a schematic diagram illustrating the advertisement 185 encoded as a portion of an LSA 450. As described above with reference to FIG. IB, the NEs 104-112 flood the network 150 with the advertisement 185 after receiving service group capability information 180 from the central entity 103.

[00101] Referring now to FIG. 4A, the advertisement 185 comprises a capability flag 303, one or more service group set IDs 145A-N, one or more service group IDs 140A-N, and one or more NE IDs 147A1-N1 to 147N1-NN for NEs 104-112 within a service group 130A-B (referred to hereinafter as“service groups 130”) or service group set 135. In an embodiment, the capability flag 303 is a flag, or a bit, that is set to indicate that an NE 104-112 sending the advertisement 185 (e.g., sending NE 104-112) is capable of implementing service groups 130 and flooding the network 150 based on the service groups 130. The service group set IDs 145A-N include one or more service group set IDs 145A-N identifying service group set 135 to which the sending NE 104-112 belongs. The service group IDs 140A-N include one or more service group IDs 140A- N identifying service groups 130 to which the sending NE 104-112 belongs. The NE IDs 147A1-N1 to 147N1-NN include labels, addresses, or IDs for each of the NEs 104-112 within a service group 130. The advertisement 185 may not necessarily include the service group set IDs 145A-N if the sending NE 104-112 is not a member of a service group 130 that is also part of a service group set 135. [00102] Referring now to FIG. 4B, shown is the portion of the LSA 450. The LSA 350 may be encoded as a Router Information (RI) opaque LSA, according to IETF RFC 770, entitled “Extensions to OSPF for Advertising Optional Router Capabilities,” by A. Lindem, et. al., dated February 2016, which is incorporated by reference herein in its entirety. It should be appreciated that LSA 450 may otherwise be any other type of LSA as defined for the OSPF protocol.

[00103] The portion of the LSA 350 shown in FIG. 3B is a type-length-value (TLV) included within the body of the RI opaque LSA. Similar to the LSA 350 of FIG. 3B, the portion of the LSA 450 includes a type field 353, a length field 356, and an informational capabilities field 359. Unlike LSA 350 of FIG. 3B, the portion of the LSA 450 includes a service grouping TLV 470, which is different from the service grouping TLV 370 of FIG. 3.

[00104] The type field 353 is a 16 bit field set to carry a value indicating that the LSA 350 carries information related to service groups 130. The length field 356 is a 16 bit field indicating a length the informational capabilities field 359.

[00105] The informational capabilities field 359 includes a plurality of bits or flags that have been assigned for various purposes. Currently bits 6-31 are unassigned. In an embodiment, one of these bits may be the capability flag 303. For example, bit 7 in the informational capabilities field 359 may be the capabilities flag 303.

[00106] The service grouping TLV 470 includes multiple service grouping sub-TLVs 475A- B. The service grouping sub-TLV 475A include a type field 453, a length field 456, and a service grouping field 457A-N. The type field 453 is a 16 bit field carrying a value that indicates that the service grouping sub-TLV 475A indicates service group set IDs 145A-N and/or service group IDs 140A-N. In an embodiment, the type field 453 may be set to 2, or any other value representing that the service grouping sub-TLV 475A indicates service group set IDs 145A-N and/or service group IDs 140A-N. The length field 456 is a 16 bit field indicating a length of the service grouping field 457A. The service grouping field 457A-N includes the service group set IDs 145A-N and/or the service group IDs 140A-N.

[00107] Each service grouping sub-TLV 475A has a corresponding service-grouping sub- TLV 475B for each service group set ID 145A-N and/or the service group ID 140A-N related to a sending NE 104-112. The service-grouping sub-TLV 475B includes a type field 459, a length field 461, and an NEs field 462A-N. The type field 459 is a 16 bit field carrying a value that indicates that the service-grouping sub-TLV 475B includes NE IDs 147A1-147N1 and 147N1- 147NN identifying NEs 104-112 within a service group 130 or a service group set 135. The length field 461 indicates a length of the NEs field 462 A-N. The NEs field 462 A includes the NE IDs 147A1-147N1 or the service group IDs 140A-N,

[00108] In some embodiments, the NEs field 462A-N may include NE IDs 147A1-147N1 or service group IDs 140A-N based on whether the service grouping field 457A-N includes service group set IDs 145A-N or the service group IDs 140A-N. When the service grouping field 457A- N includes the service group set IDs 145 A-N, the NEs field 462 A-N carries the service group IDs 140 A-N representing service groups 130 that are included in the service group set 135. When the service grouping field 457 A-N includes the service group IDs 140 A-N, the NEs field 462A-N carries the NE IDs 147A1-147N1 representing NEs that are included in the service group 130.

[00109] The portion of the LSA 450 includes service grouping sub-TLVs 475A-B for each of the service group set IDs 145A-N identifying service group set 135 and/or each of the service group IDs 140A-N identifying service groups 130 for a sending NE 104-112. The service grouping sub-TLVs 475A for the Nth service group set 135 and/or service group 130 includes a service grouping field 457N, which includes the service group set ID 145N and/or the service group ID 140N. The service grouping sub-TLVs 475B for the Nth service group set 135 and/or service group 130 includes a NEs field 462N, which includes the NE IDs 147N1-147NN.

[00110] FIG. 5 is a schematic diagram illustrating another network 500 configured to implement service groups according to various embodiments of the disclosure. Specifically, FIG. 5 illustrates a mechanism by which the NEs 501-507 in network 500 identify service group neighbors 280 (not shown in FIG. 5) that are members of a common service group 130. Network 500 includes NEs 501-507, which are each similar to NEs 104-112 of FIGS. 1 A-B.

[00111] NEs 501-507 are interconnected by links 510-516, which are each similar to links 123 of FIGS. 1A-B. In FIG. 5, NE 501 is coupled to NE 502 via link 510, NE 502 is coupled to NE 503 via link 511, NE 503 is coupled to NE 504 via link 512, NE 504 is coupled to NE 505 via link 513, NE 505 is coupled to NE 506 via link 514, NE 506 is coupled to NE 507 via link 515, and NE 507 is coupled to NE 501 via link 516.

[00112] In FIG. 5, each of NEs 501-507 has already received the advertisement 165 from each of the other NEs 501-507 in the network 500 (pursuant to the embodiment shown in FIG. 1A). Alternatively, each of the NEs 501-507 has already received the advertisement 185 from at least one other NE 501-507 in the network 500 that is communicatively coupled to the central entity 103 (pursuant to the embodiment shown in FIG. IB). In either case, each of the NEs 501-507 has updated the local database (e.g., LSDB 273) to include information regarding the service groups 130 that are provisioned across the network 500.

[00113] In the example shown in FIG. 5, five different service groups 130 are provisioned across network 500. A first service group 130 is identified by the service group ID 140 A, a second service group 130 is identified by the service group ID 140B, a third service group 130 is identified by the service group ID 140C, a fourth service group 130 is identified by the service group ID 140D, and a fifth service group 130 is identified by the service group ID 140E.

[00114] Each of the NEs 501-507 may be a member of one or more of these five service groups 130. In an embodiment, one or more of the NEs 501-507 are not a member of any service group.

[00115] In FIG. 5, NE 501 is a member of the first service group 130 and the second service group 130. As such, NE 501 is associated with both service group ID 140A and service group ID 140B, as shown in FIG. 5,

[00116] NE 502 is also a member of the first service group 130 and the second service group 130. As such, NE 502 is associated with both service group ID 140A and service group ID 140B, as shown in FIG. 5.

[00117] NE 503 is also a member of the first service group 130 and the second service group 130. As such, NE 503 is associated with both service group ID 140A and service group ID 140B, as shown in FIG. 5.

[00118] NE 504 is a member of the third service group 130 and the fourth service group 130. As such, NE 504 is associated with both service group ID 140C and service group ID 140D, as shown in FIG. 5

[00119] NE 505 is a member of the third service group 130. As such, NE 505 is then associated with service group ID 140C, as shown in FIG. 5.

[00120] NE 506 is not a member of a service group 130. As such, NE 507 is a member of the fifth service group 130. NE 507 is then associated with service group ID 140E, as shown in FIG. 5

[00121] In an embodiment, NEs 501-507 each determine service group neighbors 280. Service group neighbors 280 of a respective NE 501-507 refer to neighboring NEs 501-507 that are members of a common service group 130. For example, NE 501 first determines that NEs 502 and 507 are neighboring NEs. NE 501 and NE 507 share a common link 516, and NE 501 and NE 502 share a common link 510. NE 501 determines that NE 502 is a service group neighbor 280 for the first service group 130 and the second service group 130 because NE 502 is also a member of the first service group 130 and the second service group 130. However, NE 501 determines that NE 507 is not a service group neighbor 280 because NE 507 is not a member of the first service group 130 or the second service group 130.

[00122] NE 502 similarly determines that NEs 501 and 503 are neighboring NEs. NE 502 and NE 501 share a common link 510, and NE 502 and NE 503 share a common link 511. NE 502 also determines that NEs 501 and 503 are service group neighbors 280 for the first service group 130 and the second service group 130 because NE 501 and NE 503 are members of the first service group 130 and the second service group 130.

[00123] NE 503 similarly determines that NEs 502 and 504 are neighboring NEs. NE 503 and NE 502 share a common link 511, and NE 503 and NE 504 share a common link 512. NE 503 also determines that NEs 502 and 504 are service group neighbors 280 for the first service group 130 and the second service group 130 because NE 502 and NE 504 are members of the first service group 130 and the second service group 130.

[00124] NE 504 determines that NEs 503 and 505 are neighboring NEs. NE 504 and NE 503 share a common link 512, and NE 504 and NE 505 share a common link 513. NE 504 determines that NE 503 is not a service group neighbor 280 because NE 503 is not a member of the third service group 130 or the fourth service group 130. NE 504 determines that NE 505 is a service group neighbor 280 for the third service group 130 because NE 505 is a member of the third service group 130. [00125] NE 505 determines that NEs 504 and 506 are neighboring NEs. NE 505 and NE 504 share a common link 513, and NE 505 and NE 506 share a common link 51. NE 505 determines that NE 504 is a service group neighbor 280 for the third service group 130. NE 505 determines that NE 506 cannot be a service group neighbor 280 because NE 506 is not a member of a service group 130. Further, NE 506 cannot have a service group neighbor 280 because NE 506 is not a member of a service group 130.

[00126] NE 507 determines that NEs 506 and 501 are neighboring NEs. NE 507 and NE 506 share a common link 515, and NE 507 and NE 501 share a common link 516. NE 507 determines that NE 506 cannot be a service group neighbor 280 because NE 506 is not a member of a service group 130. NE 507 determines that NE 501 is not a service group neighbor 280 because NE 501 is not a member of the fourth service group 130.

[00127] In an embodiment, after NEs 501-507 determine the service group neighbors 280 for each of the NEs 501-507, the NEs 501-507 may update a local database (e.g., LSDB 273) to indicate the service group neighbors 280 (not shown). At this stage, each of the NEs 501-507 maintains data regarding all the service groups 130 provisioned in the network 500 and the service group neighbors 280 toward which to flood data, if needed.

[00128] FIG. 6 is a schematic diagram illustrating the flooding of data to service group neighbors 280 in the network 500 using an OSPF protocol in the flooding plane according to various embodiments of the disclosure. FIG. 6 shows network 500 including NEs 501-507 interconnected by links 510-516. Each of the NEs 501-507 maintains data regarding all the service groups 130 provisioned in the network 500 and the service group neighbors 280 toward which to flood data. [00129] In FIG. 6, NE 501 receives an advertisement 603, which is received after the advertisements 165 or 185. For example, NE 501 may receive the advertisement 603 from the central entity 103, another NE 501-507 in network 500, another NE external to the network 500, an operator of the network 500, a consumer, a client, a producer, or a service provider.

[00130] In an embodiment, the advertisement 603 is similar to the advertisements 165 and 185 in that the advertisement 603 contains information relevant to the network 500. In addition, the advertisement 603 can be encoded as an OSPF LSA. However, unlike the advertisements 165 and 185, the advertisement 603 does not include service grouping capability information 160 or 180.

[00131] In FIG. 6, the advertisement 603 includes a service group ID 140A. In an embodiment in which the first service group 130 identified by service group ID 140 A belongs to a service group set 135, the advertisement 603 also includes the service group set ID 145 identifying the service group set 135. The service group ID 140 A and the service group set ID 145 may be carried in any of the fields of an Opaque LSA, for example. An Opaque LSA is further described in the Network Working Group RFC 5250, entitled“The OSPF Opaque LSA Option,’ by L. Berger, et. ak, dated July 2008, which is incorporated by reference herein in its entirety.

[00132] While FIG. 6 only shows the advertisement 603 as including the service group ID 140A and potentially including the service group set ID 145, it should be appreciated that the advertisement 603 may include other data, such as advertisement information 666 relevant to the NEs 501-503 that are members of the first service group 130. For example, the advertisement information 666 contains application specific information relevant only to members of a particular service group 130. The advertisement 603 may also include other advertisement information 666 that is typically included in OSPF LSAs when the advertisement 603 is encoded as an OSPF LSA. While FIG. 6 shows that the advertisement 603 is associated with the first service group 130 identified by the service group ID 140 A, it should be appreciated that the advertisement 603 may be associated with any other service group 130 in the network.

[00133] After receiving the advertisement 603, NE 501 first updates a local database to include the information received in the advertisement 603. NE 501 then determines how to flood the advertisement 603 through the network 500 based on the service group 130 identified in the advertisement 603 or the service group set 135 identified by the service group set ID 145. In this way, NE 501 determines that the first service group 130 is identified in the advertisement 603 based on the service group identifier 140A or the service group set ID 145. NE 501 then performs a lookup in a local database (e.g., LSDB 273) to determine whether any of the neighboring NEs 502 and 507 are service group neighbors 280 for the first service group 130 or the service group set 135. As described above with reference to FIG. 5, NE 501 and NE 502 are service group neighbors 280 for the first service group 130 identified by the service group identifier 140A. Instead of forwarding the advertisement 603 to all neighboring NEs 502 and 507, NE 501 forwards the advertisement 603 to only NE 502, which is the only service group neighbor 280 of NE 501 for the first service group 130.

[00134] Similarly, NE 502 first updates a local database to include the information received in the advertisement 603 after receiving the advertisement 603. NE 502 also determines how to flood the advertisement 603 through the network 500 based on the service group 130 identified in the advertisement 603 or the service group set 135 identified by the service group set ID 145. In this way, NE 502 determines that the first service group 130 is identified in the advertisement 603 based on the service group identifier 140A or the service group set ID 145. NE 502 then performs a lookup in a local database to determine whether any of the neighboring NEs 503, other than the NE 501 from which the advertisement 603 was received, are service group neighbors 280 for the first service group 130 or the service group set 135. As described above with reference to FIG. 5, NE 502 and NE 503 are service group neighbors 280 for the first service group 130 identified by the service group identifier 140 A. Instead of forwarding the advertisement 603 to all neighboring NEs, NE 502 forwards the advertisement 603 to only NE 503, which is the only service group neighbor 280 of NE 502 for the first service group 130.

[00135] Similarly, NE 503 first updates a local database to include the information received in the advertisement 603 after receiving the advertisement 603. NE 503 then determines how to flood the network 500 based on the service group 130 identified in the advertisement 603 or the service group set 135 identified in the advertisement 603. In this way, NE 503 determines that the first service group 130 is identified in the advertisement 603 based on the service group identifier 140A. NE 503 then performs a lookup in a local database to determine whether any of the neighboring NEs, other than the NE 502 from which the advertisement 603 was received, are service group neighbors 280 for the first service group 130. NE 504 is not a service group neighbor 280 of NE 503 for the first service group 130. Therefore, NE 503 terminates or discontinues flooding of the advertisement 603 through network 500.

[00136] The NEs 501-507 in network 500 would have flooded the network 500 with the advertisement 603 such that every single NE 501-507 would have received and processed the advertisement 603 under the OSPF protocol. However, the embodiments disclosed herein significantly reduced the overhead on the network 500 by only flooding the advertisement 603 to NEs 501-503 that are members of the first service group 130 identified by the service group ID

140A in the advertisement 603. [00137] In another embodiment, advertisement 603 may include a service group ID 140A of “0” or“null.” Alternatively, the advertisement 603 may not include a service group ID 140A or a service group set ID 145. In this case, the advertisement 603 is flooded through the network 500 based on the OSPF flooding mechanisms. That is, NE 501 floods advertisement 603 to all neighboring NEs 502 and 507. NEs 502 and 507 determine that a service group ID 140A is set to “0,” “null,” or is otherwise not present in advertisement 603, and then floods the advertisement 603 to neighboring NEs 507 and 511. The remaining NEs 507, 506, 505, 504, 503, and 502 flood the network 500 with advertisement 603 similarly using the OSPF flooding mechanism.

[00138] In an embodiment, a service group set 135 may be signaled through an opaque AS or an area to advertise service group set 135 to NEs not participating but helping in the case of the non-adjacent neighbors. These helper NEs flood on best effort by looking up a shortest path tree to reach the neighboring NE.

[00139] The embodiments disclosed herein are advantageous in that the network overhead can be significantly reduced by reducing the amount of data that is flooded through the network 100, 150, or 500 and reducing that amount of data that has to be processed by each of NEs 104-112 or 501-507 in the network 100, 150, or 500. By forwarding advertisements 603 only to NEs 104- 112 or 501-507 in a particular service group 130, the network 100, 150, or 500 inherently will have more bandwidth by which to transmit additional data, and throughput of the network 100, 150, or 500 can be significantly increased. In addition, latency can be reduced due to the higher availability of network resources within the network 100, 150, or 500. The delay between when packets/messages are received at each of the NEs 104-112 or 501-507 and when they are processed at each of the NEs 104-112 or 501-507 can also be greatly reduced. Accordingly, the embodiments disclosed herein enhance the OSPF protocols to provide a more efficient and resource effective manner by which to flood the network 100, 150, or 500 with necessary information.

[00140] FIG. 7 A is a schematic diagram illustrating the provisioning of PPRs 710, 715, and 720 in a network 700 using service groups 130 according to various embodiments of the disclosure. As mentioned above, a PPR 710, 715, and 720 refers to a custom path or any other path that may deviate from the shortest path computed between two NEs or between a source and destination. A PPR 710, 715, and 720 may also be the same as the shortest path. PPRs 710, 715, and 720 are further defined in International Application No. PCT/US2018/015419, filed on January 28, 2019, which is incorporated by reference herein in its entirety.

[00141] FIG. 7A shows network 700, which is similar to network 100 in that network 700 includes a central entity 103 and NEs 104-112. NEs 104-112 are interconnected via links 123. The central entity 103 is connected to a single NE 109 via the central entity-to-NE link 125. Network 700 also includes NEs 701 and 702 interconnected via links 703. NE 111 is coupled to NE 701 via link 703, NE 701 is coupled to NE 702 via link 703, NE 112 is coupled to NE 702 via link 703, and NE 702 is coupled to NE 106 via link 703.

[00142] As shown by FIG. 7A, three PPRs 710, 715, and 720 have been provisioned in network 700. PPR 710 includes NE 104, NE 105, NE 106, and NE 702. PPR 715 includes NE 109, NE 108, NE 107, and NE 106. PPR 720 includes NE 109, NE 110, NE 111, NE 112, and NE 106.

[00143] The central entity 103 may determine the three PPRs 710, 715, and 720 based on user, application, or service requirements, for example. In an embodiment, the central entity 103 associates each of the PPRs 710, 715, and 720 with a service group 130. For example, PPR 710 is associated with a first service group 130, such that NEs 104, 105, 106, and 702 are members of the first service group 130. The first service group is identified by service group ID 140A.

[00144] PPR 715 is associated with a second service group 130, such that NEs 109, 108, 107, and 106 are members of the second service group 130. The second service group is identified by service group ID 140B.

[00145] PPR 720 is associated with a third service group 130, such that NEs 109, 110, 111, 112, and 106 are members of the third service group 130. The third service group is identified by service group ID 140C.

[00146] In an embodiment, each of the PPRs 710, 715, and 720 are paths associated with similar types of services or applications. In this case, the central entity 103 may group the PPRs 710, 715, and 720, and thus the corresponding service groups 130, into a single service group set 135. The service group set 135 is identified by the service group set ID 145.

[00147] In an embodiment, the central entity 103 keeps a mapping database, which includes service group mappings 279 (see FIG. 2). In an embodiment, the service group mappings 279 includes a mapping between the service group set ID 145 and the service group ID 140 A corresponding to PPR 710, the service group ID 140B corresponding to PPR 715, and the service group ID 140C corresponding to PPR 720. The mapping database also stores a mapping between PPR-IDs 750A-C and service group IDs 140A-C. The PPR-ID 750A-C is an identifier uniquely identifying a corresponding PPR 710, 715, or 720.

[00148] The service group mappings 279 also stores a mapping of each service group ID 140A-C to multiple PPR-PDEs 760AA-AN, 760BA-BN, 760CA-CN corresponding to the NEs in the service group 130/on the PPR 710, 715, and 720. Each PPR-PDE 760 contains the NE ID 147 corresponding to the NEs on the PPR 710, 715, and 720. For example, the PPR-PDEs 760AA-AN includes the labels, addresses, and IDs for NEs 104, 105, 106, and 702. The PPR- PDEs 760BA-BN includes the labels, addresses, and IDs for NEs 109, 108, 107, and 106. The PPR-PDEs 760CA-CN includes the labels, addresses, and IDs for NEs 109, 110, 111, 112, and 106.

[00149] After determining the PPRs 710, 715, and 720, and thus the first, second, and third service groups 130, the central entity 103 generates PPR information 725. As shown by FIG. 7A, the PPR information 725 includes the PPR-IDs 750A-C, the service group IDs 140A-C corresponding to each of the PPRs 710, 715, and 720, and the PPR-PDEs 760AA-AN, 760BA- BN, 760CA-CN corresponding to each of the PPRs 710, 715, and 720. In the case that the PPRs 710, 715, and 720 are grouped into a service group set 135, the PPR information 725 includes a service group set ID 145.

[00150] The central entity 103 transmits the PPR information 725 to at least one of the NEs 109 in the network 700 via a central entity-to-NE link 125. While FIG. 7A shows the PPR information 725 being sent to NE 109, it should be appreciated that the PPR information 725 may be sent to any one of the NEs 104-112 or 701-702 in the network 700.

[00151] After receiving the PPR information 725 from the central entity 103, NE 109 first updates a local database (e.g., routing table 276) to include the PPR information 725. NE 109 then initiates flooding of the PPR information 725 based on the service group set ID 145 and/or the service group IDs 140A-C in the PPR information 725. In the example shown in FIG. 7 A, NE 109 determines that neighboring NEs 108 and 110 are service group neighbors 280 based on the service group set ID 145 and/or the service group IDs 140A-C in the PPR information 725. NE 108 is a service group neighbor 280 for the second service group 130 (e.g., PPR 715), and NE 110 is a service group neighbor 280 for the third service group 130 (e.g., PPR 720). In this case, NE 109 forwards the PPR information 725 to only NEs 108 and 110, instead of blindly forwarding the PPR information 725 to all neighboring NEs.

[00152] Upon receiving the PPR information 725, NEs 108 and 110 similarly update a local database (e.g., routing table 276) to include the PPR information 725. NEs 108 and 110 also determine service group neighbors 280 that are identified based on the PPR information 725. NE 108 determines that NE 107 is a service group neighbor 280 for the second service group 130 (e.g., PPR 715). In this case, NE 108 forwards the PPR information 725 to NE 107. NE 110 determines that NE 111 is a service group neighbor 280 for the third service group 130 (e.g., PPR 720). In this case, NE 110 forwards the PPR information 725 to NE 111.

[00153] Upon receiving the PPR information 725, NEs 107 and 111 similarly update a local database (e.g., routing table 276) to include the PPR information 725. NEs 107 and 111 also determine service group neighbors 280 that are identified based on the PPR information 725. NE 107 determines that NE 106 is a service group neighbor 280 for the second service group 130 (e.g., PPR 715). In this case, NE 107 forwards the PPR information 725 to NE 106. NE 111 determines that NE 112 is a service group neighbor 280 for the third service group 130 (e.g., PPR 720). In this case, NE 111 forwards the PPR information 725 to NE 112.

[00154] Upon receiving the PPR information 725, NEs 106 and 112 similarly update a local database (e.g., routing table 276) to include the PPR information 725. NEs 106 and 112 also determine service group neighbors 280 that are identified based on the PPR information 725. NE 106 determines that NEs 105 and 112 are neighboring NEs. Since NE 112 has already received the PPR information 725 from NE 111, NE 106 only determines whether NE 105 is a service group neighbor 280 based on the PPR information 725. NE 106 determines that NE 105 is a service group neighbor 280 for the first service group 130 (e.g., PPR 710). In this case, NE 106 forwards the PPR information 725 to NE 105. NE 112 determines that NEs 106 and 702 are neighboring NEs. NE 112 determines that NE 106 has already received the PPR information 725 from NE 107, and determines the NE 702 is not a service group neighbor 280 (e.g., not identified in the PPR information 725 as belonging to any of the service groups 130). NE 112 then terminates or discontinuous forwarding of the PPR information 725.

[00155] NE 105 updates a local database (e.g., routing table 276) to include the PPR information 725. NE 105 determines that NE 104 is a service group neighbor 280 for the first service group 130 (e.g., PPR 710). In this case, NE 105 forwards the PPR information 725 to NE 104. NE 104 determines that there are no other neighboring NEs, other than NE 105 from which the PPR information 275 was received, that are service group neighbors 280. NE 104 terminates or discontinues transmission of the PPR information 725.

[00156] It should also be appreciated that the central entity 103 may have central entity-to-NE links 125 coupling the central entity 103 to all the NEs 104-112 and 701-702 in the network 700 (similar to network 100 shown in FIG. 1 A). In such a case, the central entity 103 only transmits the PPR information 725 to NEs 104, 105, 106, 107, 108, 109, 110, 111, and 112, which are part of the service groups 130 or service group set 135 identified in the PPR information 725.

[00157] Each of the NEs 104-112 and 701-702 are configured to forward subsequent advertisements that include the service group set ID 145 or service group IDs 140A-C along the same flooding topology as described above, in which the advertisements are only forwarded to NEs that are part of the service groups 130 or service group set 135 identified in the advertisement. The embodiments disclosed herein significantly reduce the overhead on the network 700 by only flooding the PPR information 725 to the NEs that are associated with the service groups 130 or service group set 135 identified in the PPR information 725. [00158] FIG. 7B is a schematic diagram illustrating the provisioning of loose PPRs 720 in network 500 using service groups 130 according to various embodiments of the disclosure. In FIG. 7B, the PPR 720 is a loose PPR 720 or a loose path. A loose PPR 720 is a PPR in which the PPR-PDEs 760CA-CN do not describe every single NE along the loose PPR 720. That is, the PPR-PDEs 760CA-CN describing a loose PPR 720 may skip certain elements along the loose PPR 720 such that only a subset of the elements along the loose PPR 720 are described in the PPR- PDEs 760CA-CN.

[00159] As shown by FIG. 7B, the PPR-PDEs 760CA-CN include an NE ID 147 for NE 109, an NE ID 147 for NE 110, an NE ID 147 for NE 111, and an NE ID 147 for NE 106. In a network implementing loose PPRs 720, the NE 111 would determine that a neighboring NE is not explicitly identified by the PPR-PDEs 760CA-CN. In such a case, NE 111 would typically forward the message to the next NE explicitly identified by the PPR-PDEs 760CA-CN along a shortest path to the NE explicitly identified by the PPR-PDEs 760CA-CN.

[00160] However, in the embodiment shown in FIG. 7B, the PPR information 725 includes a service group ID 140C corresponding to the loose PPR 720. The service group ID 140C corresponds to the third service group 130, which includes NEs 109, 110, 11, 112, and 106. That is, the service group ID 140C is associated with the NE ID 147 for NE 109, NE ID 147 for NE 110, NE ID 147 for NE 111, NE ID 147 for NE 112, and NE ID 147 for NE 106. In this embodiment, NE 111 would forward a packet (e.g., advertisement) to the service group neighbor 280 identified for the third service group 130 or PPR 720, which is NE 112, instead of having to calculate a shortest path between NE 111 to NE 106. Therefore, NEs 104-112 and 701-702 in network 700 that are configured to implement service groups 130 can forward packets more efficiently and effectively, by directly forwarding packets to service group neighbors 280, without having to inspect the PPR-PDEs 760CA-CN in the packets or calculate a shortest path.

[00161] FIG. 8 is a flowchart illustrating a method 800 for implementing service groups 130 in the control plane according to various embodiments of the disclosure. The method 800 may be performed by any one of NEs 104-112, 501-507, 701-702, or 200 (hereinafter referred to as“NE”) in networks 100, 150, 500, or 700 (hereinafter referred to as“network”). The method 800 may be performed after a central entity 103 maps a service or application to a service group 130 or service group set 135 and sends service group capability information 160 or 180 to an NE in the network.

[00162] At step 803, an NE transmits, to a neighboring NE, a first advertisement 165 or 185 comprising a service group ID 140 identifying the service group 130 and indicating that the NE is included in the service group 130. The first advertisement 165 or 185 may be generated by the NE after receiving service group capability information 160 or 180 from the central entity 103. The first advertisement 165 or 185 may be received by the NE from another NE in the network.

[00163] When the first advertisement 165 is being flooded in a network similar to network 100 of FIG. 1A, the first advertisement 165 includes the capability flag 303 and one or more service group IDs 140A-N in which the NE is a member. The first advertisement 165 may also include one or more service group set IDs 145A-N identifying one or more service group sets 135 in which the NE is a member. The first advertisement 165 may also be encoded similar to the portion of the LSA 350 of FIG. 3B.

[00164] When the first advertisement 185 is being flooded in a network similar to network 150 of FIG. IB, the first advertisement 185 includes the capability flag 303, one or more service group IDs 140A-N in which the NE is a member, and the NE labels, addresses, or IDs 147 A-N for each of the NEs in the corresponding service group 130. The first advertisement 185 may also include one or more service group set IDs 145A-N identifying one or more service group sets 135 in which the NE is a member. The first advertisement 185 may also be encoded similar to the portion of the LSA 450 of FIG. 4B.

[00165] At step 806, the NE receives a second advertisement 165 or 185 from a neighboring NE in the network. The second advertisement 165 or 185 indicates a service group capability of the neighboring NE and a service group 130 associated with the neighboring NE. In an embodiment, the second advertisement 165 or 185 comprises the service group ID 140 indicating that the neighboring NE is also included in the service group 130. The second advertisement 165 or 185 comprises the service group ID 140.

[00166] When the second advertisement 165 is being flooded in a network similar to network 100 of FIG. 1A, the second advertisement 165 includes the capability flag 303 and one or more service group IDs 140A-N in which the neighboring NE is a member. The second advertisement 165 may also include one or more service group set IDs 145A-N identifying one or more service group sets 135 in which the neighboring NE is a member. The second advertisement 165 may also be encoded similar to the portion of the LSA 350 of FIG. 3B.

[00167] When the second advertisement 185 is being flooded in a network similar to network 150 of FIG. IB, the second advertisement 185 includes the capability flag 303, one or more service group IDs 140A-N in which the neighboring NE is a member, and the NE labels, addresses, or IDs 147 A-N for each of the NEs in the corresponding service group 130. The first advertisement 185 may also include one or more service group set IDs 145 A-N identifying one or more service group sets 135 in which the neighboring NE is a member. The first advertisement 185 may also be encoded similar to the portion of the LSA 450 of FIG. 4B. [00168] At step 809, the NE determines that the NE and the neighboring NE are members of the service group 130 identified by the service group ID 140 based on the service group ID 140 in both advertisements. The NE determines that the neighboring NE is a service group neighbor 280 for the service group 130 identified by the service group ID 140.

[00169] FIG. 9 is a flowchart illustrating a method for implementing service groups in the flooding plane according to various embodiments of the disclosure. The method 900 may be performed by any one of NEs 104-112, 501-507, 701-702, or 200 (hereinafter referred to as“NE”) in networks 100, 150, 500, or 700 (hereinafter referred to as“network”). The method 900 may be performed after the NEs in the network have determined the service group neighbors 280 for any service group 130 in which the NE is a member.

[00170] At step 903, the NE receives an advertisement 603 comprising a service group ID 140 indicating a service group 130 including the NE. The advertisement 603 may also include a service group set ID 145 and any other information pertaining to the NEs within the service group 130 identified by the service group ID 140.

[00171] At step 906, the NE determines all neighboring NEs that are members of the service group 130 identified by the service group ID 140. For example, the NE determines the neighboring NEs that are service group neighbors 280 for the service group 130 identified by the service group ID 140, as described above with reference to FIG. 5.

[00172] At step 909, the NE flooding the advertisement 603 to all the neighboring NEs that are service group neighbors 280 for the service group 130 identified by the service group ID 140. As used herein, the term“flooding” refers to the forwarding of the advertisement 603 in a single direction, to ensure that the advertisement 603 is not flooded back to an NE from which the advertisement was received. In an embodiment, the NE only forwards the advertisement 603 to the neighboring NEs that are service group neighbors 280 for the service group 130 identified by the service group ID 140.

[00173] FIG. 10 is a schematic diagram illustrating an apparatus 1000 to implement service groups in the control plane according to various embodiments of the disclosure. Apparatus 1000 includes a means for transmitting 1003, a means for receiving 1006, and a means for determining 1009. The means for obtaining 1003 comprises a means for transmitting, to a neighboring NE, a first advertisement 165 or 185 comprising the service group ID 140 identifying the service group 130 and indicating that the apparatus is included in the service group 130. The means for receiving 1006 comprises a means for receiving, from the neighboring NE, a second advertisement 165 or 185 comprising the service group ID 140 and indicating that the neighboring NE is also included in the service group 130. The means for determining 1009 comprises a means for determining that the NE and the neighboring NE are members of the service group 130 based on the the service group ID 140 in both advertisements.

[00174] FIG. 11 is a schematic diagram illustrating an apparatus 1100 to implement service groups in the flooding plane according to various embodiments of the disclosure. Apparatus 1100 comprises a means for receiving 1103, a means for determining 1106, and a means for flooding 1109. The means for receiving 1103 includes a means for receiving an advertisement 603 comprising a service group ID 140 indicating a service group 130 including the NE. The means for determining 1106 includes a means for determining that all neighboring NEs that are members of the service group 130 identified by the service group ID 140. The means for flooding 1109 comprises a means for flooding the advertising 603 to all the neighboring NEs based on the service group ID 140. [00175] 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.

[00176] 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 implementing Open Shortest Path First (OSPF), comprising: transmitting, to a neighboring NE, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group; receiving, from the neighboring NE, a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group; and determining that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

2. The method according to claim 1, wherein before transmitting the first advertisement to the neighboring NE, the method further comprises receiving an advertisement comprising the service group ID from a central entity of the network or another NE in the network.

3. The method according to claim 1, wherein before transmitting the first advertisement to the neighboring NE, the method further comprises generating the first advertisement.

4. The method according to any one of claims 1 to 3, wherein the first advertisement comprises a first flag indicating that the NE is capable of implementing service group forwarding, and wherein the second advertisement comprises a second flag indicating that the neighboring NE is capable of implementing service group forwarding.

5. The method according to any one of claims 1 to 4, wherein the first advertisement comprises a plurality of service group IDs identifying a plurality of service groups, wherein the NE is a member of each of the plurality of service groups.

6. The method according to any one of claims 1 to 5, wherein the first advertisement comprises the service group ID and a plurality of IDs identifying each of the NEs that are members of the service group.

7. The method according to any one of claims 1 to 6, wherein the service group is a member of a service group set comprising a plurality of service groups, wherein a service group set ID identifies the service group set, wherein the first advertisement comprises the service group set ID, and wherein the second advertisement comprises the service group set ID.

8. The method according to claim 7, wherein the service group set is associated with a service.

9. A method performed by a network element (NE) in a network implementing Open Shortest Path First (OSPF), comprising:

receiving an advertisement comprising a service group identifier (ID) indicating a service group including the NE;

determining all neighboring NEs that are members of the service group identified by the service group ID; and

flooding the advertisement to all the neighboring NEs based on the service group ID.

10. The method according to claim 9, wherein the NE is adjacent to a plurality of neighboring NEs, wherein all neighboring NEs that are members of the service group include at least one of the plurality of neighboring NEs.

11. The method according to any one of claims 9 to 10, wherein the service group ID is 0, and wherein the method further comprises forwarding the advertisement to all neighboring NEs of the NE.

12. The method according to any one of claims 9 to 11, further comprising updating a database stored locally at the NE to include data from the advertisement.

13. A network element (NE) in a network implementing Open Shortest Path First (OSPF), comprising:

a memory storing instructions; and

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

transmit, to a neighboring NE, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group;

receive, from the neighboring NE, a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group; and determine that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

14. The NE according to claim 13, wherein, before the first advertisement is transmitted to the neighboring NE, the instructions further cause the processor to receive an advertisement comprising the service group ID from a central entity of the network or another NE in the network.

15. The NE according to claim 13, wherein, before the first advertisement is transmitted to the neighboring NE, the instructions further cause the processor to generate the first advertisement.

16. The NE according to any one of claims 13 to 15, wherein the first advertisement comprises a first flag indicating that the NE is capable of implementing service group forwarding, and wherein the second advertisement comprises a second flag indicating that the neighboring NE is capable of implementing service group forwarding.

17. The NE according to any one of claims 13 to 16, wherein the first advertisement comprises a plurality of service group IDs identifying a plurality of service groups, wherein the NE is a member of each of the plurality of service groups.

18. The NE according to any one of claims 13 to 17, wherein the first advertisement comprises the service group ID and a plurality of IDs identifying each of the NEs that are members of the service group.

19. A network element (NE) in a network implementing Open Shortest Path First (OSPF), comprising:

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

receive an advertisement comprising a service group identifier (ID) indicating a service group including the NE;

determine all neighboring NEs that are members of the service group identified by the service group ID; and

flood the advertisement to all the neighboring NEs based on the service group ID.

20. The NE according to claim 19, wherein the NE is adjacent to a plurality of neighboring NEs, wherein all neighboring NEs that are members of the service group include at least one of the plurality of neighboring NEs.

21. The NE according to any one of claims 19 to 20, wherein the service group ID is 0, and wherein the method further comprises forwarding the advertisement to all neighboring NEs of the NE.

22. The NE according to any one of claims 19 to 21, wherein the instructions further cause the processor to be configured to update a database stored locally at the NE to include data from the advertisement.

23. An apparatus, comprising: a means for transmitting, to a neighboring NE, a first advertisement comprising a service group identifier (ID) identifying a service group and indicating that the NE is included in the service group; a means for receiving, from the neighboring NE, a second advertisement comprising the service group ID and indicating that the neighboring NE is also included in the service group; and a means for determining that the NE and the neighboring NE are both members of the service group based on the service group ID in both advertisements.

24. An apparatus, comprising:

a means for receiving an advertisement comprising a service group identifier (ID) indicating a service group including the NE; a means for determining all neighboring NEs that are members of the service group identified by the service group ID; and a means for flooding the advertisement to all the neighboring NEs based on the service group ID.