Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
A request for an interview was filed with the instant response. Examiner contacted Applicant’s representative at the phone number prior to the mailing of the instant action, however, a response was not received.
Election/Restrictions
Applicant’s election without traverse of invention I, claims 1-8 and 13-20 in the reply filed on 10 June 2026 is acknowledged.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-5, 13-16 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 11658900 B2 to Holness et al. (“Holness”) in view of US 20180183654 A1 to Patel et al. (“Patel”).
Regarding claim 1, Holness taught a method comprising:
signaling, from a first provider edge device (“Provider Edge”), an extension to a virtual-network protocol (“EVPN”), the extension defining a first unique identifier corresponding to a node connected to the first provider edge device (“Customer Edge”); (consider column 1, lines 32-40, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance.”) (consider further column 2, line 38-column 3, line 2, “The present disclosure is directed to systems and methods for extending the conventional specifications and protocols related to Ethernet Virtual Private Network (EVPN) systems. In particular, the extensions to EVPN described herein are related to the ability of EVPN multi-homing groups to handle/support Operator Commands (e.g., Force Switch, Manual Switch, Clear, etc.). According to one implementation, a system includes a plurality of Ethernet Segments (ESs) and a plurality of service ports configured to communicate over the plurality of ESs. The plurality of service ports is configured to enable an operator device to access an Ethernet Virtual Private Network (EVPN) to receive Layer 2 (L2) and Layer 3 (L3) Ethernet services. The service ports are configured to enable the operator device to operate with multi-homing functionality to receive the L2 and L3 Ethernet services via redundant paths associated with the plurality of ESs. Also, the services ports are configured to respond to operator commands, the operator commands including one or more operator commands related to switching among the redundant paths. The one or more operator commands used in this system may be part of an extension of EVPN protocols. The extension of the EVPN protocols enables signaling between the operator device and the service ports to carry ES route messages that include the operator commands. The EVPN protocol extension includes an Extended Community field configured to carry the operator commands. Also, the Extended Community field may include a Designated Forwarder (DF) election sub-type for electing an active ES and one or more backup ESs as redundant paths responsive to the one or more operator commands.”) (consider further column 4, lines 30-47, “the EVPN system 10 includes an operator device 12 (e.g., a Customer Edge (CE) device, end-user device, host, etc.) configured to receive Ethernet services from an EVPN 14. The EVPN system 10 also includes an EVPN Link Aggregation Group (EVPN-LAG) 16 configured at an edge of the EVPN 14. In some embodiments, the EVPN-LAG 16 may include one or more edge devices 18-1, 18-2, . . . , 18-n (e.g., one or more Service Provider devices, Provider Edge (PE) devices, etc.). Each edge device 18 may include one or more ports 20-1, 20-2, . . . , 20-n. It should be noted that the one or more of edge devices 18 may include multiple ports 20 in this EVPN-LAG. The operator device 12 is connected to the ports 20-1, 20-2, . . . , 20-n via a plurality of links 22-1, 22-2, . . . , 22-n forming a Link Aggregation (LAG) 24, which may be defined by IEEE 802.1AX and which may be run with or without Link Aggregation Control Protocol (LACP).”) (consider further column 7, lines 48-61, “The presence of an operator command is signaled between the devices with the multi-homing redundancy group. This signaling can be instantiated via extensions to existing EVPN messaging (e.g., EVPN Ethernet Segment Route messages). In some embodiments, the EVPN extension may include a specific field in the EVPN Ethernet Segment Route message (or associated Extended Community fields). For example, this field can be defined to allow the EVPN-LAG 16 to carry the operational commands, particularly those commands related to protection switching operations, such as Lockout, Force Switch, Manual Switch, Manual Revert, Revert Mode Selection, Clear, etc. There may be numerous ways that the operator commands can be encoded in the messages or fields.”) and
sending, from the first provider edge device, the one or more messages to a second provider edge device (“remote Provider Edge” “device” which is also a “BGP peer”), wherein traffic from the second provider edge device to the node are routed along a path that includes the first provider edge device. (again, consider column 1, lines 32-40 and 49-61, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance…Also, EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system.”) (consider column 8, lines 3-7, “In an EVPN, a Designated Forwarder (DF) may be defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device (e.g., a Customer Edge (CE) device).”)
Holness may be interpreted as not expressly teaching monitoring, by the first provider edge device, one or more states associated with the node; initiating a performance measurement session between the first provider edge device and a second provider edge device, and the performance measurement session includes sending one or more messages having a field that encodes state information representing the one or more states associated with the node, wherein respective portions of the field correspond to respective monitored entities associated with the node, and wherein values within the respective portions represent states of the corresponding monitored entities, however, Holness did teach initiating a performance measurement session related to one or more states associated with the node. (consider column 6, line 57-column 7, line 13, “FIGS. 3A-3C are diagrams illustrating modes of the EVPN system 10 in response to a Manual Switch command. In this second example of protection-related commands, a network operator may wish to perform a network maintenance action on a backup path (e.g., backup link 22-2), as shown in the mode of FIG. 3A. This backup path is part of a redundancy or protection group (e.g., EVPN-LAG 16) where one or more backup paths are available when routing is switched away from the primary path. From the original mode, the network operator may wish to invoke a command to cause the link to be tested (e.g., backup link 22-2). Thus, the network operator issues a Manual Switch command. In this case, for maintenance purposes, data traffic may be switched away from the active link (e.g., link 22-1) to the standby/backup link 22-2 within the EVPN-LAG 16, as shown in FIG. 3B. The EVPN-LAG 16 causes the active port (e.g., port 20-1) to be out-of-service and switches for the backup port (e.g., port 20-2) to become active. However, during the testing, the backup link 22-2 may detect a failure. If it is determined (e.g., using a signal detector) that there is a fault (e.g., Signal Failure (SF)) on the backup link 22-2, as shown in FIG. 3C, the EVPN-LAG 16 may be configured to switch back to the original active link 22-1, where port 20-1 becomes active again.”)
In an analogous art relating to edge device messaging paths, Patel taught monitoring (“detecting”), by a first edge device (“local” “provider edge device”), one or more states associated with a node (“provider edge device (PE)”) (whether an “Ethernet segment”/”virtual Layer 2 bridged connectivity” “between” “customer edge devices” and a “provider edge device” has “failed”; consider paragraph 0001 regarding the “failure” of “an Ethernet segment indicator (ESI)” “at a provider edge (PE) device”); (consider paragraph 0001, specifically “According to the Ethernet virtual private network (EVPN) Fast Withdraw procedure, when an Ethernet segment indicator (ESI) failure occurs at a provider edge (PE) device, Border Gateway Protocol (BGP) is used to withdraw an Ethernet Auto Discovery (EAD)/Ethernet segment (ES) route from the PE device (e.g., the local BGP peer) pertaining to the failed ESI. When a remote BGP peer receives notification of the withdrawal of the EAD/ES route from the local BGP peer, the remote BGP peer locally withdraws the same EAD/ES route. In addition, the remote BGP peer removes the IP address of the local BGP peer from the equal-cost-multi-path (ECMP) path for forwarding for the failed ESI.”) (consider further paragraphs 0015 and 0024 wherein “the EVPN can include a plurality of provider edge devices 102, 104, 106, and 108 and a plurality of customer edge devices 110 and 120” such that “The provider edge devices 102, 104, 106, and 108 can be configured to provide virtual Layer 2 bridged connectivity between the customer edge devices 110 and 120. As described below, the provider edge devices 102, 104, 106, and 108 can be configured to detect an Ethernet segment failure in the EVPN according to the techniques described herein, e.g., by extending BFD to achieve rapid and efficient ESI-level failure detection” and that “a local peer (e.g., a provider edge device shown in FIG. 1) can monitor for failure of an Ethernet segment, i.e., a set of one or more Ethernet communication links. An Ethernet segment can optionally be a port channel or port bundle. For example, an Ethernet segment can connect the local peer to a customer edge device shown in FIG. 1”)
initiating a performance measurement session between the first provider edge device and a second provider edge device (“remote peer”/”another provider edge device”), (consider paragraph 0025, specifically “the local peer can establish a BFD session with a remote peer (e.g., another provider edge device shown in FIG. 1). The local and remote peers can be communicatively connected via a network (e.g., the IP infrastructure shown in FIG. 1), e.g., a VXLAN or MPLS network. The BFD protocol provides a low-overhead, short-duration (e.g., as fast as about 50 milliseconds) mechanism to detect failures in the forwarding path between adjacent network devices. The BFD protocol can be enabled on the local and remote peers at Layer 2 and Layer 3. Using the BFD protocol, a BFD session can be created and the local and remote peers can begin to transmit and receive BFD control packets over the network (e.g., VXLAN or MPLS network)”) and the performance measurement session includes sending one or more messages (“BFD control packet(s)”) having a field that encodes state information representing the one or more states associated with the node, wherein respective portions of the field correspond to respective monitored entities (“ES”) associated with the node, and wherein values within the respective portions represent states of the corresponding monitored entities (the “ESI index” containing a “bitmap” that “can indicate a functional locally configured ESI” or “can indicate a failed locally configured ESI”). (consider paragraphs 0027 and 0030 wherein “An example BFD control packet according to Katz, D. et al., RFC 5880—Bidirectional Forwarding Detection (BFD) can include” “State (Sta): The current BFD session state as seen by the transmitting system”) (consider further paragraph 0047, specifically “At 306, the local peer can transmit the BFD control packet to the remote peer over the network (e.g., VXLAN or MPLS network). The BFD control packet can include a notification of the failure of the Ethernet segment. In other words, the notification of the failure of the Ethernet segment can be added to the BFD control packet…Each Ethernet segment in the EVPN can be assigned an ESI, which is typically a 10 byte value. In order to efficiently include the notification of the failure of an Ethernet segment in a BFD control packet, the local peer can maintain an ESI index…Each of the entries in the ESI index 400 can store a respective status of a locally configured ESI. For example, a value of “1” can indicate a functional locally configured ESI, and a value of “0” can indicate a failed locally configured ESI. In addition, an entry in the ESI index 400 can be updated (e.g., entry value changed from “1” to “0”) in response to detecting the failure of an Ethernet segment. In other words, the ESI index 400 can be a bitmap, e.g., each of the entries of the ESI index can have a length of 1 bit, and the value of an entry (e.g., a bit) can be updated or changed in response to detecting the failure of an Ethernet segment. By using a bitmap, it is possible to indicate the statuses of locally configured ESI's more efficiently. For example, if the local peer has sixty-four locally configured port channels (e.g., 64 ESI's), the ESI index has a length of only 8 bytes (e.g., 1 bit per locally configured ESI). The ESI index can therefore provide a single, efficiently packed message that is capable of tracking a large number of ESI's. As described below, by transmitting the ESI index to remote peer(s), it is possible for the remote peer(s) to monitor availability of ESI's configured on the local peer. Upon receipt of the ESI index from the local peer, the remote peer can remove the EAD/ES route more rapidly withdraw EAD/ES routes as compared to the conventional technique for EAD/ES route withdrawal using BGP. Additionally, a single BFD session between the local and remote peers can be used to track all of the ESI's”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, the Examiner finds that, based on the references' analogous disclosure regarding edge device messaging paths, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Regarding claim 2, the combined teachings of Holness and Patel taught the method of claim 1.
Holness may be interpreted as not expressly teaching wherein the one or more states associated with the node are a state of an ethernet segment that connects the node with the first provider edge device, host states of one or more hosts on the node, application states of one or more applications running on the node, or VM states of one or more virtual machines (VMs) on the node, however, Patel did teach these limitations. (again, consider paragraphs 0027 and 0030 wherein “An example BFD control packet according to Katz, D. et al., RFC 5880—Bidirectional Forwarding Detection (BFD) can include” “State (Sta): The current BFD session state as seen by the transmitting system”) (again, consider paragraph 0047, specifically “At 306, the local peer can transmit the BFD control packet to the remote peer over the network (e.g., VXLAN or MPLS network). The BFD control packet can include a notification of the failure of the Ethernet segment. In other words, the notification of the failure of the Ethernet segment can be added to the BFD control packet…Each Ethernet segment in the EVPN can be assigned an ESI, which is typically a 10 byte value. In order to efficiently include the notification of the failure of an Ethernet segment in a BFD control packet, the local peer can maintain an ESI index…Each of the entries in the ESI index 400 can store a respective status of a locally configured ESI. For example, a value of “1” can indicate a functional locally configured ESI, and a value of “0” can indicate a failed locally configured ESI…As described below, by transmitting the ESI index to remote peer(s), it is possible for the remote peer(s) to monitor availability of ESI's configured on the local peer. Upon receipt of the ESI index from the local peer, the remote peer can remove the EAD/ES route more rapidly withdraw EAD/ES routes as compared to the conventional technique for EAD/ES route withdrawal using BGP. Additionally, a single BFD session between the local and remote peers can be used to track all of the ESI's”)
The motivations regarding the obviousness of claim 1 also apply to claim 2, therefore, claim 2 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Holness and Patel and the same rationale supporting the conclusion of obviousness.
Regarding claim 3, the combined teachings of Holness and Patel taught the method of claim 1.
Holness taught wherein a first ethernet segment connects the node to the first provider edge device. (again, consider column 1, lines 32-40, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance.”)
Patel also taught these limitations. (consider paragraphs 0015 and 0024 wherein “the EVPN can include a plurality of provider edge devices 102, 104, 106, and 108 and a plurality of customer edge devices 110 and 120” such that “The provider edge devices 102, 104, 106, and 108 can be configured to provide virtual Layer 2 bridged connectivity between the customer edge devices 110 and 120. As described below, the provider edge devices 102, 104, 106, and 108 can be configured to detect an Ethernet segment failure in the EVPN according to the techniques described herein, e.g., by extending BFD to achieve rapid and efficient ESI-level failure detection” and that “a local peer (e.g., a provider edge device shown in FIG. 1) can monitor for failure of an Ethernet segment, i.e., a set of one or more Ethernet communication links. An Ethernet segment can optionally be a port channel or port bundle. For example, an Ethernet segment can connect the local peer to a customer edge device shown in FIG. 1”)
Holness may be interpreted as not expressly teaching wherein the one or more states associated with the node are a liveness state of the first ethernet segment, however, Patel did teach these limitations. (again, consider paragraphs 0027 and 0030 wherein “An example BFD control packet according to Katz, D. et al., RFC 5880—Bidirectional Forwarding Detection (BFD) can include” “State (Sta): The current BFD session state as seen by the transmitting system”) (again, consider paragraph 0047, specifically “At 306, the local peer can transmit the BFD control packet to the remote peer over the network (e.g., VXLAN or MPLS network). The BFD control packet can include a notification of the failure of the Ethernet segment. In other words, the notification of the failure of the Ethernet segment can be added to the BFD control packet…Each Ethernet segment in the EVPN can be assigned an ESI, which is typically a 10 byte value. In order to efficiently include the notification of the failure of an Ethernet segment in a BFD control packet, the local peer can maintain an ESI index…Each of the entries in the ESI index 400 can store a respective status of a locally configured ESI. For example, a value of “1” can indicate a functional locally configured ESI, and a value of “0” can indicate a failed locally configured ESI…As described below, by transmitting the ESI index to remote peer(s), it is possible for the remote peer(s) to monitor availability of ESI's configured on the local peer. Upon receipt of the ESI index from the local peer, the remote peer can remove the EAD/ES route more rapidly withdraw EAD/ES routes as compared to the conventional technique for EAD/ES route withdrawal using BGP. Additionally, a single BFD session between the local and remote peers can be used to track all of the ESI's”)
The motivations regarding the obviousness of claim 1 also apply to claim 3, therefore, claim 3 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Holness and Patel and the same rationale supporting the conclusion of obviousness.
Regarding claim 4, the combined teachings of Holness and Patel taught the method of claim 1.
Holness taught wherein the first unique identifier is manually provisioned or the first unique identifier is provisioned by a controller. (again, consider column 1, lines 32-40 and 49-61, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance…Also, EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system.”) (consider further column 3, line 66-column 4, line 17, “In various embodiments, the present disclosure relates to systems and methods for extending Ethernet Virtual Private Network (EVPN) specifications and protocols. In particular, the present systems and methods are configured to provide an extension of EVPN specifications by allowing the management of operator commands related to protection switching functionality. For example, protection switching is related to allowing multiple connection paths to provide redundancy for a Customer Edge (CE) device, end-user device, host, etc. In this way, the CE device can access multiple ports of one or more Provider Edge (PE) devices to receive Ethernet services from an EVPN. In the context of an EVPN system, a PE may be configured as a router between one Service Provider's area and those areas administered by other Service Providers (e.g., Internet Service Provider). A CE may also be a router at a customer premises and may be connected to the PE of the Service Provider's Internet Protocol (IP) or Multi-Protocol Label Switching (MPLS) network.”)
Regarding claim 5, the combined teachings of Holness and Patel taught the method of claim 1.
Holness taught wherein the virtual-network protocol is an Ethernet virtual private network (EVPN) protocol. (consider column 1, lines 17-61 regarding the state of the art regarding “EVPN” as is well known in the art)
Holness may be interpreted as not expressly teaching the performance measurement session is initiated using a protocol selected from a group consisting of a Two-Way Active Measurement Protocol (TWAMP), a Simple Two-Way Active Measurement Protocol (STAMP), bi-directional forwarding (BFD) protocol, the one or more messages are messages of the performance measurement session, and the field is a type-length-value field that includes a value representing whether a failure has occurred with respect to the node, and monitoring the one or more states associated with the node is performed using a local optics check for an interface failure, a local connectivity fault management (CFM) protocol, a bi-directional forwarding detection (BFD) protocol, or a local performance measurement session, however, Patel did teach these limitations. (consider paragraph 0015 wherein “the EVPN can include a plurality of provider edge devices 102, 104, 106, and 108 and a plurality of customer edge devices 110 and 120” such that “The provider edge devices 102, 104, 106, and 108 can be configured to provide virtual Layer 2 bridged connectivity between the customer edge devices 110 and 120. As described below, the provider edge devices 102, 104, 106, and 108 can be configured to detect an Ethernet segment failure in the EVPN according to the techniques described herein, e.g., by extending BFD to achieve rapid and efficient ESI-level failure detection”) (consider further paragraph 0026, specifically “(consider further paragraphs 0027 and 0030 wherein “BFD control packets can be sent in an encapsulation appropriate to the environment (e.g., VXLAN or MPLS) as discussed above. A BFD control packet can include a Mandatory Section and an optional Authentication Section” and “An example BFD control packet according to Katz, D. et al., RFC 5880—Bidirectional Forwarding Detection (BFD) can include” “State (Sta): The current BFD session state as seen by the transmitting system”) (consider further paragraph 0047, specifically “At 306, the local peer can transmit the BFD control packet to the remote peer over the network (e.g., VXLAN or MPLS network). The BFD control packet can include a notification of the failure of the Ethernet segment. In other words, the notification of the failure of the Ethernet segment can be added to the BFD control packet…Each Ethernet segment in the EVPN can be assigned an ESI, which is typically a 10 byte value. In order to efficiently include the notification of the failure of an Ethernet segment in a BFD control packet, the local peer can maintain an ESI index…Each of the entries in the ESI index 400 can store a respective status of a locally configured ESI. For example, a value of “1” can indicate a functional locally configured ESI, and a value of “0” can indicate a failed locally configured ESI…As described below, by transmitting the ESI index to remote peer(s), it is possible for the remote peer(s) to monitor availability of ESI's configured on the local peer. Upon receipt of the ESI index from the local peer, the remote peer can remove the EAD/ES route more rapidly withdraw EAD/ES routes as compared to the conventional technique for EAD/ES route withdrawal using BGP. Additionally, a single BFD session between the local and remote peers can be used to track all of the ESI's”)
Holness may also be interpreted as not expressly teaching within the virtual-network protocol is an Ethernet virtual private network (EVPN) protocol on an VXLAN virtual network, however, Holness did teach wherein the virtual-network protocol is an Ethernet virtual private network (EVPN) protocol and also taught that it was known to use EVPN with BGP in order to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. (again, consider column 1, lines 32-40).
Patel taught that the use of an VXLAN virtual network was well known in the art as an overlay over network infrastructures and further taught that using EVPN in conjunction with such a VXLAN was also known (consider paragraphs 0015-0016).
The motivations regarding the obviousness of claim 1 also apply to claim 5, therefore, claim 5 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Holness and Patel and the same rationale supporting the conclusion of obviousness.
Claims 13-16 recite a system comprising a first provider edge device comprising a first processor and a first memory storing instructions (consider column 11, lines 18-61 of Holness) that, when executed by the first processor, configure the first provider edge to perform substantially the same limitations as recited in claim(s) 1, 2, 4 and 5 respectively and are also rejected under 35 USC § 103 as being unpatentable over the same combined teachings of Holness and Patel and the same rationale supporting the conclusion of obviousness.
Regarding claim 19, the combined teachings of Holness and Patel taught the system of claim 13.
Holness taught a second provider edge device (“remote Provider Edge” “device” which is also a “BGP peer”) comprising: a second processor; and a second memory storing instructions (consider column 11, lines 18-61) that, when executed by the second processor, configure the second provider edge device to:
receive, from the first provider edge device, a signal including one or more instructions to apply the extension to the virtual-network protocol. (again, consider column 1, lines 32-40, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance”) (again, consider column 2, line 38-column 3, line 2, “The present disclosure is directed to systems and methods for extending the conventional specifications and protocols related to Ethernet Virtual Private Network (EVPN) systems. In particular, the extensions to EVPN described herein are related to the ability of EVPN multi-homing groups to handle/support Operator Commands (e.g., Force Switch, Manual Switch, Clear, etc.). According to one implementation, a system includes a plurality of Ethernet Segments (ESs) and a plurality of service ports configured to communicate over the plurality of ESs. The plurality of service ports is configured to enable an operator device to access an Ethernet Virtual Private Network (EVPN) to receive Layer 2 (L2) and Layer 3 (L3) Ethernet services. The service ports are configured to enable the operator device to operate with multi-homing functionality to receive the L2 and L3 Ethernet services via redundant paths associated with the plurality of ESs. Also, the services ports are configured to respond to operator commands, the operator commands including one or more operator commands related to switching among the redundant paths. The one or more operator commands used in this system may be part of an extension of EVPN protocols. The extension of the EVPN protocols enables signaling between the operator device and the service ports to carry ES route messages that include the operator commands. The EVPN protocol extension includes an Extended Community field configured to carry the operator commands. Also, the Extended Community field may include a Designated Forwarder (DF) election sub-type for electing an active ES and one or more backup ESs as redundant paths responsive to the one or more operator commands.”)
send the traffic to the node, the traffic being routed along the path from the second provider edge device to the node including the first provider edge device; receive, from the first provider edge device, the one or more messages; and perform a failover action when the state information encoded in the field of the one or more messages indicates a failure associated with the node or a degradation of communications between the first provider edge device and the node. (again, consider column 1, lines 32-40 and 49-61, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance…Also, EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system.”) (consider column 8, lines 3-7, “In an EVPN, a Designated Forwarder (DF) may be defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device (e.g., a Customer Edge (CE) device).”) (consider further column 6, line 57-column 7, line 20, “FIGS. 3A-3C are diagrams illustrating modes of the EVPN system 10 in response to a Manual Switch command. In this second example of protection-related commands, a network operator may wish to perform a network maintenance action on a backup path (e.g., backup link 22-2), as shown in the mode of FIG. 3A. This backup path is part of a redundancy or protection group (e.g., EVPN-LAG 16) where one or more backup paths are available when routing is switched away from the primary path. From the original mode, the network operator may wish to invoke a command to cause the link to be tested (e.g., backup link 22-2). Thus, the network operator issues a Manual Switch command. In this case, for maintenance purposes, data traffic may be switched away from the active link (e.g., link 22-1) to the standby/backup link 22-2 within the EVPN-LAG 16, as shown in FIG. 3B. The EVPN-LAG 16 causes the active port (e.g., port 20-1) to be out-of-service and switches for the backup port (e.g., port 20-2) to become active. However, during the testing, the backup link 22-2 may detect a failure. If it is determined (e.g., using a signal detector) that there is a fault (e.g., Signal Failure (SF)) on the backup link 22-2, as shown in FIG. 3C, the EVPN-LAG 16 may be configured to switch back to the original active link 22-1, where port 20-1 becomes active again. Since the Signal Failure (on the protection path) is the second highest priority command/mode in the above priority list, this detected condition may cause the automatic switch back to the active/primary link 22-1. However, in some embodiments, the EVPN-LAG 16 may be configured to switch back to the active link in response to receiving a Clear command.”)
Holness may be interpreted as not expressly teaching wherein the second provider edge device is to instantiate the performance measurement session between the second provider edge device and the first provider edge device, however, Holness did teach initiating a performance measurement session related to one or more states associated with the node. (consider column 6, line 57-column 7, line 13, “FIGS. 3A-3C are diagrams illustrating modes of the EVPN system 10 in response to a Manual Switch command. In this second example of protection-related commands, a network operator may wish to perform a network maintenance action on a backup path (e.g., backup link 22-2), as shown in the mode of FIG. 3A. This backup path is part of a redundancy or protection group (e.g., EVPN-LAG 16) where one or more backup paths are available when routing is switched away from the primary path. From the original mode, the network operator may wish to invoke a command to cause the link to be tested (e.g., backup link 22-2). Thus, the network operator issues a Manual Switch command. In this case, for maintenance purposes, data traffic may be switched away from the active link (e.g., link 22-1) to the standby/backup link 22-2 within the EVPN-LAG 16, as shown in FIG. 3B. The EVPN-LAG 16 causes the active port (e.g., port 20-1) to be out-of-service and switches for the backup port (e.g., port 20-2) to become active. However, during the testing, the backup link 22-2 may detect a failure. If it is determined (e.g., using a signal detector) that there is a fault (e.g., Signal Failure (SF)) on the backup link 22-2, as shown in FIG. 3C, the EVPN-LAG 16 may be configured to switch back to the original active link 22-1, where port 20-1 becomes active again.”)
In an analogous art relating to edge device messaging paths, Patel taught wherein a second provider edge device (“remote peer”/”another provider edge device”) is configured to instantiate the performance measurement session between the second provider edge device and the first provider edge device. (consider paragraph 0025, specifically “the local peer can establish a BFD session with a remote peer (e.g., another provider edge device shown in FIG. 1). The local and remote peers can be communicatively connected via a network (e.g., the IP infrastructure shown in FIG. 1), e.g., a VXLAN or MPLS network. The BFD protocol provides a low-overhead, short-duration (e.g., as fast as about 50 milliseconds) mechanism to detect failures in the forwarding path between adjacent network devices. The BFD protocol can be enabled on the local and remote peers at Layer 2 and Layer 3. Using the BFD protocol, a BFD session can be created and the local and remote peers can begin to transmit and receive BFD control packets over the network (e.g., VXLAN or MPLS network)”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, the Examiner finds that, based on the references' analogous disclosure regarding edge device messaging paths, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Regarding claim 20, the combined teachings of Holness and Patel taught the system of claim 19.
Holness further taught wherein the node is multihomed with the first provider edge device and with a third provider edge device, (consider column 1, line 49-column 2, line 4, “EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system. In EVPNs, a Designated Forwarder (DF) is defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device. A preferred DF is selected from a number of PEs for operation as an active connection, while one or more backup DFs may be selected for operation as backup connections. Service Providers allow a way to force a DF switchover in order to carry out some maintenance tasks on the preferred DF and control how backup DFs may be utilized”) (consider further column 8, lines 3-16, “In an EVPN, a Designated Forwarder (DF) may be defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device (e.g., a Customer Edge (CE) device). A preferred DF is selected from a number of PEs in the EVPN-LAG 16 for operation as an “active” connection (e.g., working connection, primary connection, etc.), while one or more DFs may be selected for operation as “backup” connections (e.g., protection connections, standby connections, etc.). DF switchover may be allowed at certain times (e.g., during maintenance, when a fault is detected, etc.) in order to switch from the active connection to one of the backup connections to allow data packets to continue to be transmitted in a system”)
the failover action is for the second provider edge device to direct the traffic to the third provider edge device, when the one or more messages indicate the failure of communication between the first provider edge device and the node, and the failover action is performed when the field indicates the failure associated with the node is (i) an absence of communication between the first provider edge device and the node, (ii) an indication of non-liveness of a first ethernet segment between the node and the first provider edge device, (iii) an indication of traffic loss between the first provider edge device and the node has exceeded a first predefined threshold, or (iv) an indication of jitter between the first provider edge device and the node has exceeded a second predefined threshold. (again, consider column 1, lines 32-40 and 49-61, “EVPN uses Border Gateway Protocol (BGP) signaling to establish the EVPN instance (EVI) with BGP peers to offer a multipoint-to-multipoint L2 Ethernet service for a given client. EVPN relies on learning the Internet Protocol (IP) and Media Access Control (MAC) address binding of the locally connected Customer Edge (CE) devices and distributing this information in the BGP EVPN Protocol Data Units (PDUs) to remote Provider Edge (PE) devices that are members of the established EVPN instance…Also, EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system.”) (consider further column 6, line 57-column 7, line 20, “FIGS. 3A-3C are diagrams illustrating modes of the EVPN system 10 in response to a Manual Switch command. In this second example of protection-related commands, a network operator may wish to perform a network maintenance action on a backup path (e.g., backup link 22-2), as shown in the mode of FIG. 3A. This backup path is part of a redundancy or protection group (e.g., EVPN-LAG 16) where one or more backup paths are available when routing is switched away from the primary path. From the original mode, the network operator may wish to invoke a command to cause the link to be tested (e.g., backup link 22-2). Thus, the network operator issues a Manual Switch command. In this case, for maintenance purposes, data traffic may be switched away from the active link (e.g., link 22-1) to the standby/backup link 22-2 within the EVPN-LAG 16, as shown in FIG. 3B. The EVPN-LAG 16 causes the active port (e.g., port 20-1) to be out-of-service and switches for the backup port (e.g., port 20-2) to become active. However, during the testing, the backup link 22-2 may detect a failure. If it is determined (e.g., using a signal detector) that there is a fault (e.g., Signal Failure (SF)) on the backup link 22-2, as shown in FIG. 3C, the EVPN-LAG 16 may be configured to switch back to the original active link 22-1, where port 20-1 becomes active again. Since the Signal Failure (on the protection path) is the second highest priority command/mode in the above priority list, this detected condition may cause the automatic switch back to the active/primary link 22-1. However, in some embodiments, the EVPN-LAG 16 may be configured to switch back to the active link in response to receiving a Clear command.”)
Claim(s) 6-7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Holness and Patel as applied to claims 1 and 13 above, and further in view of US 9929940 B2 to Singh.
Regarding claim 6, the combined teachings of Holness and Patel taught the method of claim 1.
Holness taught wherein the node is multihomed at the first provider edge device and a third provider edge device. (consider column 1, line 49-column 2, line 4, “EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system. In EVPNs, a Designated Forwarder (DF) is defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device. A preferred DF is selected from a number of PEs for operation as an active connection, while one or more backup DFs may be selected for operation as backup connections. Service Providers allow a way to force a DF switchover in order to carry out some maintenance tasks on the preferred DF and control how backup DFs may be utilized”) (consider further column 8, lines 3-16, “In an EVPN, a Designated Forwarder (DF) may be defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device (e.g., a Customer Edge (CE) device). A preferred DF is selected from a number of PEs in the EVPN-LAG 16 for operation as an “active” connection (e.g., working connection, primary connection, etc.), while one or more DFs may be selected for operation as “backup” connections (e.g., protection connections, standby connections, etc.). DF switchover may be allowed at certain times (e.g., during maintenance, when a fault is detected, etc.) in order to switch from the active connection to one of the backup connections to allow data packets to continue to be transmitted in a system”)
Holness and Patel may be interpreted as not expressly teaching wherein the node is advertised, via the virtual-network protocol, to the second provider edge device as receiving traffic either through the first provider edge device or through the third provider edge device, however, Holness did teach that an extension of the virtual-network protocol is used within messages sent (consider column 10, lines 32-42, “The one or more operator commands may be part of an extension of EVPN protocols. The extension of the EVPN protocols may enable signaling between the operator device and the service ports to carry ES route messages that include the operator commands. The EVPN extension may also include an Extended Community field configured to carry the operator commands. The Extended Community field, for example, may include a Designated Forwarder (DF) election sub-type for electing an active ES and one or more backup ESs as redundant paths responsive to the one or more operator commands.”)
In an analogous art relating to virtual-network protocol extensions and multi-homed nodes connected to provider edge nodes, Singh taught that a node connected to a first provider edge device is advertised, via a virtual-network protocol, to a second provider edge device as receiving traffic either through the first provider edge device or through a third provider edge device. (consider column 1, line 62-column 2, line 41, “In an EVPN, MAC learning between PE network devices occurs in the control plane rather than in the data plane (as happens with traditional bridging) using a routing protocol. For example, in EVPNs, a PE network device typically uses the Border Gateway Protocol (BGP) (i.e., an L3 routing protocol) to advertise to other provider edge network devices the MAC addresses learned from the local consumer edge network devices to which the PE network device is connected. A PE device may use BGP route advertisement message to announce reachability information for the EVPN, where the BGP route advertisement specifies one or more MAC addresses learned by the PE network device instead of L3 routing information. In an EVPN configuration referred to as single-active mode, an Ethernet segment includes multiple PE network devices that provide multi-homed connectivity for one or more local customer network devices. Moreover, the multiple PE network device provide transport services through the intermediate network to a remote PE network device, and one of the multiple PE network devices in the Ethernet segment operates as a designated forwarder to forward Ethernet frames in the segment for the customer network device. The remaining PE network devices that provide the customer network device multi-homed connectivity in the Ethernet segment are configured as backup PE network devices. When a network failure occurs with respect to the current designated forwarder, the backup PE network devices may execute a designated forwarder election algorithm to determine which of the backup PE network devices will become the new designated forwarder and, as a result, assume responsibility for forwarding network layer two communications for the customer network device. The techniques described herein extend existing EVPN protocol signaling mechanisms so that local, multi-homing PEs coupled to an Ethernet segment can definitively convey their primary/backup status to any remote PE of the EVPN. In one example, this is accomplished by utilizing a new extended community attribute in each Ethernet A-D per EVI route advertised by each of the multi-homing PEs to specifically carry the advertising PE's primary or backup status. As such, any receiving remote PE need not rely on the arrival of individual MAC routes from a new primary PE and withdrawal of MAC routes from a former primary PE to update its forwarding state.”) (consider further column 6, lines 6-23, “For example, in typical operation, PE routers 10A-10D communicate using the Border Gateway Protocol (BGP) and the EVPN protocol specifies BGP Network Layer Reachability Information (NLRI) for the EVPN and may define different route types for conveying EVPN information via the BGP routing protocol. The EVPN NLRI is typically carried in BGP using BGP Multiprotocol Extensions. An Ethernet Segment route advertised by each PE router 10A-10C using BGP includes a Route Distinguisher and Ethernet Segment Identifier. An Ethernet AD route advertised by each PE router 10A-10C for each EVI, specifies a Route Distinguisher (RD) (e.g., an IP address of an MPLS Edge Switch (MES)), ESI, Ethernet Tag Identifier, and MPLS label. Subsequent BGP media access control (MAC) routes output by PE router 10A-10C announce MAC addresses of customer equipment 4 for the EVPN include a RD, ESI, Ethernet Tag Identifier, MAC address and MAC address length, IP address and IP address length, and MPLS label.”) (consider further column 6, lines 55-66, “Moreover, as PE routers 10 learn the MAC address for customer equipment 4 reachable through local attachment circuits, the PE routers 10 utilize MAC address route advertisements of a layer three (L3) routing protocol (i.e., BGP in this example) to share the learned MAC addresses and to provide an indication that the MAC addresses are reachable through the particular PE router that is issuing the route advertisement. In the EVPN implemented using PE routers 10 for a given EVI, each of PE routers 10 advertises the locally learned MAC addresses to other PE routers 10 using a BGP route advertisement, also referred to herein as a “MAC route” or a “MAC Advertisement route.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, Examiner finds that, based on the references' analogous disclosure regarding virtual-network protocol extensions and multi-homed nodes connected to provider edge nodes, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Regarding claim 7, the combined teachings of Holness, Patel and Singh taught the method of claim 6.
Holness may be interpreted as not expressly teaching wherein, when the state information indicates a failure of a connection between the first provider edge device and the node, ceasing to receive the traffic along the path from the second provider edge device to the node including the first provider edge device, however, Holness did teach receiving the traffic along another path from the second provider edge device to the node including the third provider edge device upon failure of a connection between the first provider edge device and the node. (again, consider column 1, line 49-column 2, line 4, “EVPN systems provide multi-homing functionality allowing a computer network (e.g., a Customer Edge (CE) device, an end-user device, a host, etc.) to be connected to more than one network via a plurality of Ethernet Segments (ESs). Thus, with multi-homing, multiple redundant connections or paths can be available for increasing the reliability and performance of Ethernet services to the CE device. For example, if one path fails or degrades, data packets can be transmitted through one or more backup or protection paths. In some cases, multiple simultaneous connections can be used through a system for more efficient routing. Thus, multi-homing can allow for single-active or all-active access to an EVPN system. In EVPNs, a Designated Forwarder (DF) is defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device. A preferred DF is selected from a number of PEs for operation as an active connection, while one or more backup DFs may be selected for operation as backup connections. Service Providers allow a way to force a DF switchover in order to carry out some maintenance tasks on the preferred DF and control how backup DFs may be utilized”) (consider further column 8, lines 3-16, “In an EVPN, a Designated Forwarder (DF) may be defined as a device (e.g., a Provider Edge (PE) device) responsible for sending Broadcast, Unknown unicast, and Multicast (BUM) traffic to a multi-homed device (e.g., a Customer Edge (CE) device). A preferred DF is selected from a number of PEs in the EVPN-LAG 16 for operation as an “active” connection (e.g., working connection, primary connection, etc.), while one or more DFs may be selected for operation as “backup” connections (e.g., protection connections, standby connections, etc.). DF switchover may be allowed at certain times (e.g., during maintenance, when a fault is detected, etc.) in order to switch from the active connection to one of the backup connections to allow data packets to continue to be transmitted in a system”) (consider further column 8, line 64-column 9, line 1, “If a local fault occurs on the primary connection (e.g., port 20-1, link 22-1), then the EVPN-LAG 16 is configured to dispatch an ES Route with EVPN Extended Community of sub-type 0x06 (DF Election Extended Community) with Signal Failure (SF) code 1011 to peer.”)
Patel taught wherein the state information indicates a failure of a connection between the first provider edge device and the node, ceasing to receive the traffic along the path from the second provider edge device to the node including the first provider edge device. (again, consider paragraph 0015, specifically “As described below, the provider edge devices 102, 104, 106, and 108 can be configured to detect an Ethernet segment failure in the EVPN according to the techniques described herein, e.g., by extending BFD to achieve rapid and efficient ESI-level failure detection.”) (again, consider paragraphs 0015 and 0024 wherein “the EVPN can include a plurality of provider edge devices 102, 104, 106, and 108 and a plurality of customer edge devices 110 and 120” such that “The provider edge devices 102, 104, 106, and 108 can be configured to provide virtual Layer 2 bridged connectivity between the customer edge devices 110 and 120. As described below, the provider edge devices 102, 104, 106, and 108 can be configured to detect an Ethernet segment failure in the EVPN according to the techniques described herein, e.g., by extending BFD to achieve rapid and efficient ESI-level failure detection” and that “a local peer (e.g., a provider edge device shown in FIG. 1) can monitor for failure of an Ethernet segment, i.e., a set of one or more Ethernet communication links. An Ethernet segment can optionally be a port channel or port bundle. For example, an Ethernet segment can connect the local peer to a customer edge device shown in FIG. 1”) (again, consider paragraphs 0027 and 0030 wherein “An example BFD control packet according to Katz, D. et al., RFC 5880—Bidirectional Forwarding Detection (BFD) can include” “State (Sta): The current BFD session state as seen by the transmitting system”) (again, consider paragraph 0047, specifically “At 306, the local peer can transmit the BFD control packet to the remote peer over the network (e.g., VXLAN or MPLS network). The BFD control packet can include a notification of the failure of the Ethernet segment. In other words, the notification of the failure of the Ethernet segment can be added to the BFD control packet…Each Ethernet segment in the EVPN can be assigned an ESI, which is typically a 10 byte value. In order to efficiently include the notification of the failure of an Ethernet segment in a BFD control packet, the local peer can maintain an ESI index…Each of the entries in the ESI index 400 can store a respective status of a locally configured ESI. For example, a value of “1” can indicate a functional locally configured ESI, and a value of “0” can indicate a failed locally configured ESI…As described below, by transmitting the ESI index to remote peer(s), it is possible for the remote peer(s) to monitor availability of ESI's configured on the local peer. Upon receipt of the ESI index from the local peer, the remote peer can remove the EAD/ES route more rapidly withdraw EAD/ES routes as compared to the conventional technique for EAD/ES route withdrawal using BGP. Additionally, a single BFD session between the local and remote peers can be used to track all of the ESI's”)
The motivations regarding the obviousness of claim 1 also apply to claim 7, therefore, claim 7 is rejected under 35 USC § 103 as being unpatentable over the combined teachings of Holness and Patel and the same rationale supporting the conclusion of obviousness.
Claim 17 recites a system comprising a first provider edge device comprising a first processor and a first memory storing instructions (consider column 11, lines 18-61 of Holness) that, when executed by the first processor, configure the first provider edge to perform substantially the same limitations as recited in claim 6 and is also rejected under 35 USC § 103 as being unpatentable over the same combined teachings of Holness, Patel and Singh and the same rationale supporting the conclusion of obviousness.
Allowable Subject Matter
Claims 8 and 18 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant's arguments filed in the instant response have been fully considered but they are not persuasive.
Applicant argues that “Claim 1 has been amended to recite, inter alia, "wherein respective portions of the field correspond to respective monitored entities associated with the node, and wherein values within the respective portions represent states of the corresponding monitored entities." Holness is directed to communicating operator commands in an EVPN multihoming environment, such as Force Switch, Manual Switch, Signal Failure, and related protection- switching operations. Holness uses EVPN protocol extensions to communicate operator commands and designated-forwarder information among PE devices. See, e.g., Holness, col. 1, 11. 32-67; col. 2, 11. 1-21; col. 7, 11. 25-67. Holness does not disclose monitoring one or more states associated with a node and does not disclose encoding node state information into messages of a performance measurement session.”
However, Applicant then states that “Patel, as characterized by the Examiner, fails to cure the deficiencies of Holness. Therefore, a hypothetical combination of Holness and Patel fails to render obvious the features recited in claim 1. Claim 13 recites features that are somewhat similar to those recited in claim 1. Therefore, a hypothetical combination of Holness and Patel also fails to render obvious the features recited in claim 13 as well as claims 2-7, 14-17, 19, and 20 that depend from one of claims 1 and 13.”
Given that the claimed limitations that are further defined in the instant amendments, particularly the “field that encodes state information”, were shown to be taught in Patel, not Holness, Applicant’s argument that merely states that “Patel, as characterized by the Examiner, fails to cure the deficiencies of Holness. Therefore, a hypothetical combination of Holness and Patel fails to render obvious the features recited in claim 1” amounts to a general allegation that the combination of Holness and Patel do not teach the invention as amended. Applicant has provided no specific argument about how the teachings of Patel “fails to cure the deficiencies of Holness”. Therefore, Examiner finds that Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections. As such, they are unpersuasive to remove the rejection of record and, while the rejection has been updated to reflect the instant amendments, the combined teachings of Holness and Patel continue to teach the claimed invention. As shown in the updated rejection below, Examiner finds that Patel, which was previously shown to teach the “field that encodes state information” as claimed, does teach the amended limitations.
Claims 8 and 18 continue to be objected to as being dependent upon a rejected base claim but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
An updated search revealed additional prior art that is considered pertinent to the amended claimed invention and/or to the broader disclosure. Consider US 20220294728 A1 to Liu.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to G. C. Neurauter, Jr. whose telephone number is (571)272-3918. The examiner can normally be reached Monday-Friday 9am-5pm Eastern Time.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached at 571-272-4170. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/G. C. Neurauter, Jr./Primary Examiner, Art Unit 2459
Prosecution Insights