DETAILED ACTION
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 .
This office correspondence is in response to the application number 18/578924 filed on January 12, 2024.
Preliminary Amendment
Prior to examination on the merits, Applicant has requested amendments to the claims for examination. The amendments are accepted.
Claims 11 - 12 are amended.
Claim 10 is cancelled.
Claims 13 – 21 are added.
Claims 1 – 9 and 11 - 21 are rejected.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This Application is the National Stage filing under 35 U.S.C. § 371 of PCT Application Ser. No. PCT/CN2022/104902 filed on July 11,2022 which claims the benefit of Chinese Patent Application No. 202110797837.3, filed with the China National Intellectual Property Administration on July 14, 2021 and entitled "Method and Apparatus for Looking Up Forwarding Table, Storage Medium, and Electronic Device". The applicant is entitled to a priority date of 7/14/2021.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on January 12, 2024 and October 15, 2024 were filed on or after the mailing date of the application on January 12, 2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
35 USC § 101 Analysis – Judicial Exception
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception.. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for looking up a forwarding table, a storage medium, and an electronic device, the claimed invention reciting steps to controlling a Virtual Routing and Forwarding (VRF) table to be registered to an Ethernet Virtual Private Network (EVPN), such that the EVPN generates a Route Type-5 (RT5) route corresponding to a service route, wherein the RT5 route carries an IP prefix Prefix1, and in a case of detecting that an Internet Protocol (IP) address of a next hop of the service route is IP1, determining a Media Access Control (MAC) address M1, which is obtained by performing Address Resolution Protocol (ARP) parsing and corresponds to IP1, as an overlay index of the RT5 route, and advertising the RT5 route to the EVPN, and further where a Provider Edge PE3 receives the RT5 route, generating a routing table entry according to Prefix1 carried in the RT5 route, and looking up a MAC forwarding table from a Supplementary Broadcast Domain (SBD) of an IP-VRF instance according to the overlay index M1 of the RT5 route, wherein the overlay index is an index that is used for performing, in an overlay network, iterative table-lookup for a packet. The ordered steps of the claim language solve a problem known in the art that in the case where the ESI service is busy, the traffic from PE3 to CE1 is pushed to PE2, and since there is no local routing to CE1 on PE2, the MAC forwarding table of the VPLS cannot be found according to the next hop, resulting in that PE3 cannot forward the traffic to CE1 from the ESI. Therein the claims are statutory under 35 USC 101.
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 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 of this title, 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.
Claims 1 – 9 and 11 - 21 are rejected under 35 U.S.C. 103 as being un-patentable over Lin et al. (U.S. 2016/0277210 A1; herein referred to as Lin) in view of Singh et al. (U.S. 2017/0289033 A1; herein referred to as Singh)
In regard to claim 1, Lin teaches A method for looking up a forwarding table (see ¶ [0007] “ . . . The techniques described herein may improve inter-subnet multicast forwarding in an EVPN when delivering multicast traffic to receivers on a different IP subnet than the multicast source . . .”; see ¶ [0031] “ . . . In multi-homed environments EVPN defines a mechanism to signal, to remote PEs, the need to update their forwarding tables upon the occurrence of a failure in connectivity to an Ethernet segment. . .”), comprising:
controlling a Virtual Routing and Forwarding (VRF) table to be registered to an Ethernet Virtual Private Network (EVPN), such that the EVPN generates a Route Type-5 (RT5) route corresponding to a service route, wherein the RT5 route carries an IP prefix Prefix1 (see ¶¶ [0030-0032] “ . . . As described above, PEs 10 may use control plane signaling with different route types to provision the EVPN service in service provider network 12. EVPN defines BGP Network Layer Reachability Information (NLRI), and in particular, defines different route types. The EVPN NLRI is carried in BGP using BGP Multiprotocol Extensions. Route types include but are not limited to: Ethernet Auto-Discovery (AD) routes, MAC advertisement routes, and Ethernet Segment Routes. AD routes, for example, specify a Route Distinguisher (RD) (e.g., an IP address of an MPLS Edge Switch (MES)), ESI, Ethernet Tag Identifier, and MPLS label. MAC advertisement routes include a RD, ESI, Ethernet Tag Identifier, MAC address and MAC address length, IP address and IP address length, and MPLS label. An Ethernet Segment route includes a Route Distinguisher and Ethernet Segment Identifier. PEs 10 and CEs 8 may share NLRI to configure one or more Ethernet segments and share MAC routes that are learned by the respective devices. In general, PEs connected to the same Ethernet segment can automatically discover each other with minimal to no configuration through the exchange of the Ethernet Segment route using BGP. In multi-homed environments EVPN defines a mechanism to signal, to remote PEs, the need to update their forwarding tables upon the occurrence of a failure in connectivity to an Ethernet segment. This is done by having each PE advertise an Ethernet AD Route per Ethernet segment for each locally attached segment which indicates the reachability of the PE in the Ethernet segment. Upon a failure in connectivity to the attached segment, the PE withdraws the corresponding Ethernet AD route by sending an AD route withdrawal message to other PEs. This triggers all PEs that receive the withdrawal to update their next-hop adjacencies for all MAC addresses associated with the Ethernet segment specified by the Ethernet AD route. If no other PEs had advertised an Ethernet AD route for the same segment, then the PE that received the withdrawal simply invalidates the MAC entries for that segment. In some examples, one or more of PEs 10 may embed Network Virtualization Edge (NVE) functionality within the respective PEs, as described in “Network Virtualization Edge (NVE),” Feb. 13, 2014, https://tools.ietf.org/html/draft-yong-nvo3-nve-03, which is hereby incorporated by reference herein in its entirety. In some examples, a PE that implements NVE functionality may be referred to as an NVE device. As shown in FIG. 1, each of PEs 10 may implement Virtual Routing Functionality (VRF). For example, PEs 10A-10C include VRFs 22A-22C, respectively. Each of VRFs 22A-22C (“VRFs 22”), as shown in FIG. 1, logically represent an instance of Virtual Routing Functionality implemented at the respective PE. Generally, VRF permits multiple routing tables to exist within a single physical router. An attachment circuit may be associated with a particular VRF, and the particular VRF may be configured to forward traffic for the attachment circuit. VRFs 22 may be configured to include functionality described in “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006, https://tools.ietf.org/html/rfc4364, which is hereby incorporated by reference herein in its entirety . . .”).;
in a case of detecting that an Internet Protocol (IP) address (see ¶ [0030] “ . . . , for example, specify a Route Distinguisher (RD) (e.g., an IP address of an MPLS Edge Switch (MES)), ESI, Ethernet Tag Identifier, and MPLS label. MAC advertisement routes include a RD, ESI, Ethernet Tag Identifier, MAC address and MAC address length, IP address and IP address length, and MPLS label. An Ethernet Segment route includes a Route Distinguisher and Ethernet Segment Identifier. . . .”) of a next hop of the service route is IP1 (see ¶ [0031] “ . . . having each PE advertise an Ethernet AD Route per Ethernet segment for each locally attached segment which indicates the reachability of the PE in the Ethernet segment. Upon a failure in connectivity to the attached segment, the PE withdraws the corresponding Ethernet AD route by sending an AD route withdrawal message to other PEs. This triggers all PEs that receive the withdrawal to update their next-hop adjacencies for all MAC addresses associated with the Ethernet segment specified by the Ethernet AD route . . .”), determining a Media Access Control (MAC) address M1 (see ¶ [0024] “ . . . In the example of FIG. 1, when providing the EVPN service to customer networks 18, PEs 10 and CEs 20 typically perform MAC address learning to efficiently forward L2 network communications in system 2. That is, as PEs 10 and CEs 20 forward Ethernet frames, the routers learn L2 state information for the L2 network, including media access control (MAC) addressing information for customer equipment 4 within the network and the physical ports through which customer equipment 4 are reachable. PEs 10 and CEs 8 typically store the MAC addressing information in MAC tables associated with respective interfaces. When forwarding an individual Ethernet frame received on one interface, a router typically broadcasts the Ethernet frame to all other interfaces associated with the EVPN unless the router has previously learned the destination L2 address (e.g., MAC address) specified in the Ethernet frame. In this case, the router forwards a single copy of the Ethernet frame out the associated interface . . .”) , (see ¶ [0025] “ . . . As PEs learn the MAC address for customer equipment 4 reachable through local attachment circuits, the PEs 10 utilize 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 that is issuing the route advertisement. In the EVPN implemented in system 2, each of PEs 10 advertises the locally learned MAC addresses to other PEs 10 using a BGP route advertisement, also referred to herein as a “MAC route” or a “MAC Advertisement route.” As further described below, a MAC route typically specifies an individual MAC address of a customer equipment 4 along with additional forwarding information, such as a route descriptor, route target, layer 2 segment identifier, MPLS label, etc. In this way, PEs 10 use BGP to advertise and share the MAC addresses learned when forwarding layer two communications associated with the EVPN. . . .”) ; and
in a case where a Provider Edge PE3 (see Fig. 1 PE 10) receives the RT5 route (see ¶ [0026] “. . . In this way, PEs 10 may perform both local learning and remote learning of MAC addresses. Each of PEs 10 utilizes MAC routes specifying the MAC addresses learned by other PE routers to determine how to forward L2 communications to MAC addresses that belong to customer equipment 4 connected to other PEs, i.e., to remote CEs and/or customer equipment behind CEs operatively coupled to PEs. That is, each of PEs 10 determines whether Ethernet frames can be sent directly to a particular one of the other PEs or whether to treat the Ethernet frames as so called “BUM” traffic (Broadcast, Unidentified Unicast or Multicast traffic) that is to be flooded within the EVPN based on the MAC addresses learning information received from the other PE router . . .”), generating a routing table entry according to Prefix1 carried in the RT5 route (see Fig. 1 ¶¶ [0028-0029] “. . . As shown in FIG. 1, CE router 20A is singly-homed to PE 10A by an Ethernet link that constitutes an “Ethernet segment.” In the case of a CE that is multi-homed to multiple PE routers, each Ethernet link between the CE and the multiple PEs may be included in a uniquely identifiable Ethernet Segment. Ethernet segments have an identifier, called the “Ethernet Segment Identifier” (ESI), which may be encoded as a ten octets integer. In general, an Ethernet segment uses a non-reserved ESI that is unique network wide (e.g., across all EVPNs on all the PEs). In some examples, a network operator may manage ESIs throughout the EVPN to ensure unique network wide ESIs for respective Ethernet segments. In other examples, ESIs may be allocated automatically. In this example of FIG. 1, an Ethernet segment that includes PE 10A and CE 20A may be associated with a unique ESI. Using ESIs, PEs 10 may share learned MAC addresses by sending MAC Advertisement routes that specify, among other information, a learned MAC address and a corresponding ESI. In this way, PEs 10 may maintain tables of MAC addresses associated with corresponding ESIs. Consequently, a PE that receives and maintains MAC addresses that were previously learned by other PEs 10 can determine that a MAC route is accessible through multiple PE routers that are associated with the same ESI . . .”) ,
Lin fails to explicitly teach,
However Singh teaches
which is obtained by performing Address Resolution Protocol (ARP) parsing and corresponds to IP1, as an overlay index (e.g. entry for in the address cache) of the RT5 router (see Singh ¶ [0027] “ . . . An address cache manager of a particular VTEP may maintain and populate the address cache for the particular VTEP in various ways. For example, the address cache manager 212 may parse an ARP broadcast request received from a locally hosted or locally linked overlay network tenant, such as VM-A or VM-B. The ARP broadcast request may specify an IP address-MAC address mapping for the source tenant (e.g., VM-A), which the address cache manager 212 may parse from the ARP address request and add an entry for in the address cache 211 . . .”)
and looking up a MAC forwarding table from a Supplementary Broadcast Domain (SBD) (see ¶ [0016] “ . . . In the particular example shown in FIG. 1, the address cache manager 114 may include the modules 121, 122, 123, and 124 to implement various features that the address cache manager 114 may provide. As described in greater detail below, the address cache manager 114 (e.g., through the modules 121-124) may maintain the address cache 112 to map IP addresses of virtual machines in the overlay network to corresponding MAC addresses of virtual machines in an overlay network; receive an address resolution protocol (ARP) broadcast request from a first virtual machine hosted with the VTEP, the ARP broadcast request including a target IP address of a second virtual machine to resolve; access the address cache 112 to identify a particular MAC address of the second virtual machine that maps to the target IP address; and locally respond to the ARP broadcast request to resolve the target IP address without broadcasting the ARP broadcast request to other virtual machines in the overlay network. . . “) of an IP-VRF instance according to the overlay index M1 of the RT5 route (see Singh ¶ [0027] “ . . . the address cache manager 212 may parse an ARP response received through the overlay network 230 to identify an IP address-MAC address mapping of the overlay network tenant sending the ARP response, such as VM-C for example. Accordingly, the address cache manager 212 may perform an address cache update through entry insertion of an IP address-MAC address mapping identified through parsing an address resolution broadcast request, an address resolution response, or both . . .”) ,
wherein the overlay index (e.g. entry of the address cache) is an index that is used for performing, in an overlay network, iterative table-lookup for a packet (see Singh ¶ [0014] “ . . . In the example shown in FIG. 1, the VTEP 110 includes an address cache 112 and an address cache manager 114. The address cache 112 may be implemented as a cache, table, database, or other storage entity that stores address mappings for tenants of a VXLAN overlay network. A tenant of the overlay network may take the form of, as examples, a virtual machine (VM), server, or other computing device. In some examples, the address cache 112 of the VTEP 110 stores L3 to L2 address mappings for virtual machines or other end devices in the overlay network, and particularly IP address to media access control (MAC) address mappings for tenants of an overlay network. An entry of the address cache 112 may thus store the IP address for a virtual machine (or other tenant) in the overlay network as well as the corresponding MAC address for the virtual machine. In that regard, the address cache 112 may be distinct and store different information from a forwarding table of a VTEP, which may instead map MAC addresses of remote tenants in the overlay network to the IP addresses of the remote VTEPs associated with the remote tenant . . .” see Singh ¶ ¶ [0030-0031] “ . . . the address cache manager 212 generates the address cache learn message 310 as an overlay packet, e.g., as a VXLAN overlay packet meeting the packet format of VXLAN overlay packets. To identify the address cache learn message 310 as an address cache-related communication intended for processing by a receiving address cache manager of another VTEP, the address cache manager 212 may, for example, set particular header bits of in the VXLAN header or otherwise identify the address cache learn message 310 as an address cache-related communication. Accordingly, an address cache manager receiving an address cache learn message may parse a packet header to identify and process the address cache learn message, e.g. by inserting an entry into its address cache with the IP address-MAC address mapping(s) specified in the address cache learn message. In the example shown in FIG. 3, upon receiving the address cache learn message 310 from the address cache manager 212, the address cache manager 222 of the VTEP 220 may update its address cache 221 by adding an entry for the IP address-MAC address mapping specified in the address cache learn message 310. The address cache manager 212 may generate and send the address cache learn message 310 in response to any number of events, triggers, or other criteria. In one example, the address cache manager 212 may generate the address cache learn message 310 in response to adding a new entry into its address cache 211, e.g., upon learning a particular IP address-MAC address mapping for an overlay network tenant that is not already stored in the address cache 211. In another example, the address cache manager 212 may generate the address cache learn message 310 in response to parsing an ARP broadcast request received from an associated overlay network tenant and identifying the source IP address and source MAC address of the associated overlay network tenant. In yet another example, the address cache manager 212 may generate the address cache learn message 310 upon receiving an ARP response from a remote tenant and parsing the ARP response to identify the IP address-MAC address mapping of the remote tenant, the local tenant to which the ARP response is directed to, or both. The address cache manager 212 may send the address cache learn message 310 to other VTEPs for an overlay network in none, some, or all of the above example triggers. . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s invention to incorporate a system and method for address resolution in a network for guiding a data packet from a source to a destination by implementing an address cache for IP to MAC mapping when an address resolution request is broadcast from a virtual machine, as taught by Singh, into a system and method for improving multicast forwarding in an Ethernet Virtual Private Network (EVPN) when delivering multicast traffic to receivers on a different IP subnet than the multicast source, the EVPN transports L2 communications, such as Ethernet packets or “frames,” between customer networks via traffic engineered label switched paths (LSP) through the intermediate network in accordance with one or more multiprotocol label switching (MPLS) protocols, as taught by Lin. Such incorporation enables a MAC forwarding table to be maintained while traffic is routed on the EVPN.
In regard to claim 2, the combination of Lin and Singh teaches wherein before controlling the VRF table to be registered to the EVPN, such that the EVPN generates the RT5 route corresponding to the service route (see Lin ¶ [0030] “ . . . PEs 10 may use control plane signaling with different route types to provision the EVPN service in service provider network 12. EVPN defines BGP Network Layer Reachability Information (NLRI), and in particular, defines different route types. The EVPN NLRI is carried in BGP using BGP Multiprotocol Extensions. Route types include but are not limited to: Ethernet Auto-Discovery (AD) routes, MAC advertisement routes, and Ethernet Segment Routes. AD routes, for example, specify a Route Distinguisher (RD) (e.g., an IP address of an MPLS Edge Switch (MES)), ESI, Ethernet Tag Identifier, and MPLS label. MAC advertisement routes include a RD, ESI, Ethernet Tag Identifier, MAC address and MAC address length, IP address and IP address length, and MPLS label. An Ethernet Segment route includes a Route Distinguisher and Ethernet Segment Identifier. . . .”), the method further comprises:
configuring an EVPN Virtual Private Local Area Network Service (VPLS) Layer-2 instance BD1 (e.g. first L2 domain) for PE1, and configuring an EVPN VPLS Layer-2 instance BD2 (e.g. second L2 domain) for PE2, wherein the BD1 and the BD2 do not import routes of each other (see Lin Fig. 6, ¶¶ [0078-0080] “ . . . FIG. 6 is flowchart illustrating example operations of a network device that may improve inter-subnet multicast forwarding in an EVPN when delivering multicast traffic to receivers on different IP subnet, in accordance with techniques of the disclosure. For purposes of illustration, the example operations are described below within the context of PE 10A of this disclosure. PE 10A may configure first and second L2 domains (200). For instance, PE 10A may configure VLAN1 as a first L2 domain that corresponds to IP subnet SN1, as shown in FIG. 1. PE 10A may also configure VLAN2 as a second L2 domain that corresponds to IP subnet SN2, as shown in FIG. 1. PEs 10B and 10C may be similarly configured to forward network traffic using VLAN1 and VLAN2. PE 10A may configure a first layer-3 Integrated Routing and Bridging (IRB) interface for the first layer-2 domain, e.g., VLAN1 and a second IRB for the second layer-2 domain, e.g., VLAN2 (202). For instance PE 10A may configure IRB1 as shown in FIG. 1 to receive network traffic on VLAN1. PE 10A may also configure IRB2 as shown in FIG. 1 to forward network traffic on VLAN2. In some examples, PE 10A may also configure IRB2 to receive network traffic from IRB1, such that IRB2 receives multicast traffic from IRB1 that originated on VLAN1 and forwards the multicast traffic on VLAN2. PE 10A may receive a network packet in multicast traffic from multicast source device 4A (204). Multicast source 4A may be included in the first layer-2 domain, VLAN1. The network packet in the multicast traffic may be destined for a multicast receiver 4B, which is included in the second layer-2 domain, VLAN2. In response to receiving the network packet, PE 10A may forward, using the layer-3 IRB interface, the network packet to the multicast receiver 4B (206). In this way, the network packet may follow path 31 as shown in FIG. 1, rather than being forwarded to the PIM-DR PE 10C before being forwarded again by PE 10A to multicast receiver 4B. As such, the network packet may be forwarded by PE 10A to multicast receiver 4B without receiving the multicast packet from another PE 10C that has been elected as the DR on the second IRB interface for the second layer-2 domain . . . “)
In regard to claim 3, the combination of Lin and Singh teaches wherein the SBD permits importing of the routes of the BD1 and the BD2 (see Lin Fig. 1, ¶¶ [0039-0040] “ . . . In FIG. 1, as described above, VLAN1 and VLAN2 may define two separate layer-2 domains. For each layer-2 domain in the EVPN, there may be a respective, corresponding layer-3 IP subnet in the PIM network. That is, there may be two separate layer-3 domains in the PIM network. In the example of FIG. 1, a first layer-3 IP subnet SN1 corresponds to VLAN1, and a second layer-3 IP subnet SN2 corresponds to VLAN2. For each layer-3 IP subnet, one of PEs 10 may be designated as the designated router (DR or PIM-DR in this disclosure). The DR for a particular layer-3 IP subnet is responsible for sending multicast traffic to other remote PEs in the same layer-3 IP subnet. In this way, the DR is used to centralize the forwarding of multicast traffic for a particular layer-3 IP subnet to prevent multiple PEs from sending the same multicast traffic. PEs 10 may elect a DR using one or more election techniques, such described in “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006, https://tools.ietf.org/html/rfc4601, which is hereby incorporated by reference herein in its entirety. In the example of FIG. 1, PE router 10C is the DR for SN1 and is also the DR for SN2. Conventionally, if multicast source 4A sent multicast traffic originating within VLAN1, PE 10A would forward the multicast traffic to each of PEs 10B and 10C based on PIM Join messages that originated from multicast receivers 4B-4E and were previously forwarded by PEs 10B and 10C to PE 10A. In this process, PE 10B would forward the multicast traffic to multicast receiver 4C on VLAN1; however, because PE 18B is not the PIM-DR for bridging the layer-3 IP subnets SN1 and SN2 that correspond to the layer-2 VLAN1 and VLAN2, PE 18B may not forward the multicast traffic to multicast receiver 4D on VLAN2. Instead, when the PIM-DR PE 10C receives the multicast traffic from PE 10A, PE 10C bridges the multicast traffic from VLAN1 to VLAN2 by forwarding the multicast traffic from IRB 28C to IRB 30C. IRB 30C then broadcasts the multicast traffic to PEs 10A and 10B, which in turn forward the multicast traffic to multicast receivers 4B and 4D, respectively. In this conventional technique, the multicast traffic is forwarded by PE 10A to the PIM-DR PE 10C, which then bridges the traffic using one or more IRBs and sends the traffic back to PE 10A. . . .”)
In regard to claim 4, the combination of Lin and Singh teaches wherein the SBD does not advertise an Inclusive Multicast Ethernet Tag (IMET) route to PE1 or PE2 (see Lin Fig. 5, ¶¶ [0076-0077] “ . . . As shown in FIG. 5, is possible that a particular NVE, such as NVE2, may not have an IRB interface. For receivers on the same L2 domain (i.e. on same IP subnet) as the multicast source, such as TS231, the multicast traffic will be delivered by NVE1-NVE3 based on EVPN BUM procedure. If, however, a multicast receiver is on a different L2 domain (i.e. on different subnets) as the multicast source, such as multicast receiver TS232 and multicast source TS11, the multicast receiver TS232 receives the multicast traffic from one of NVEs that has the IRB on the same L2 domain as the receivers. For example, NVE3 has an IRB on the same L2 domain as multicast receiver TS323. Therefore, NVE3 forwards the multicast traffic received from multicast receiver TS11 from VLAN1 to VLAN2 and forwards the multicast traffic using IRB2 to multicast receiver TS232 on VLAN2. Multicast receiver TS232 receives the multicast traffic from the DR, NVE3, of that subnet VLAN2. In some examples, if an NVE does not have any IRBs, such as NVE2, then the DR, NVE3, may use a separate provider tunnel to deliver traffic only to sites that do not have IRB interfaces. For instance, NVE3 may advertise the tunnel to NVE2 via a separate Multicast Ethernet Tag Route . . .”)
In regard to claim 5, the combination of Lin and Singh teaches wherein an IP address of an Intergraded Routing and Bridging (IRB) interface of the SBD is in an unnumbered form (see Singh ¶¶ [0032-0034] “ . . . one or more of PEs 10 may embed Network Virtualization Edge (NVE) functionality within the respective PEs, as described in “Network Virtualization Edge (NVE),” Feb. 13, 2014, https://tools.ietf.org/html/draft-yong-nvo3-nve-03, which is hereby incorporated by reference herein in its entirety. In some examples, a PE that implements NVE functionality may be referred to as an NVE device. As shown in FIG. 1, each of PEs 10 may implement Virtual Routing Functionality (VRF). For example, PEs 10A-10C include VRFs 22A-22C, respectively. Each of VRFs 22A-22C (“VRFs 22”), as shown in FIG. 1, logically represent an instance of Virtual Routing Functionality implemented at the respective PE. Generally, VRF permits multiple routing tables to exist within a single physical router. An attachment circuit may be associated with a particular VRF, and the particular VRF may be configured to forward traffic for the attachment circuit. VRFs 22 may be configured to include functionality described in “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006, https://tools.ietf.org/html/rfc4364, which is hereby incorporated by reference herein in its entirety. As shown in FIG. 1, multiple Virtual Local Area Networks (VLANs) may be configured by PEs 10. Accordingly, PEs 10 may forward network packets (e.g., multicast packets) to between customer networks 18 using multiple layer 2 subnetworks. PEs 10 may be configured to implement VLANs that are identified by identifiers VLAN1 and VLAN2. As shown in FIG. 1, PEs 10A-10C may include VLAN1 instances 24A and VLAN2 instances 26A. Each instance may represent functionality implemented by the respective PE for forwarding network packets within one or more layer 2 subnetworks identified by the respective one or more VLAN identifiers. One or more of PEs 10 may implement Integrated Routing and Bridging (IRB), which support layer-2 bridging and layer-3 routing on the same interface. As such, IRB allows a router to route local packets to another routed interface or to another bridging domain that has a layer-3 protocol configured. Accordingly, one or more IRB interfaces (or “IRBs”) may be used to locally route inter-subnet traffic. For instance, using one or more IRBs, a PE may route inter-subnet traffic between VLAN1 and VLAN2. In the example of FIG. 1, PE 10A includes IRBs 28A, 30A; PE 10B includes IRBs 28B, 30B; and PE 10C includes IRBs 28C, 30C. PE 10A may route traffic between VLAN1 24A and VLAN2 26A using one or more of IRBs 28A and 30A. One or more of PEs 10 may implement IRB as described in “Integrated Routing and Bridging in EVPN”, ietf-bess-evpn-inter-subnet-forwarding, Nov. 11, 2014, https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-00, which is hereby incorporated by reference herein in its entirety. IRB interfaces are L3 interfaces associated with layer-2 domains. A PE connects to layer-2 domains using L2 interfaces. With conventional PIM (L3 protocol) behavior, only the DR of a L3 interface will forward multicast traffic to local receivers; however, techniques of this disclosure allow non-DR on IRB interfaces to forward multicast traffic to local receivers, thus avoiding hair pinning, and the IRB interface is bound to the IP-VRF instance (see Singh Fig. 1 ¶¶ [0032-0034] “ . . . As shown in FIG. 1, PEs 10 may be configured with one EVI, and under the single EVI there are two bridge domains with VLAN1 and VLAN2, respectively. Although not shown in FIG. 1, PEs 10 may configure two EVIs, EVI1 and EVI2, which correspond respectively to VLAN1 and VLAN2. PEs 10 share the same EVI1 and EVI2 that correspond to the two domains VLAN1 and VLAN 2. Both EVI1 and EVI2 belong to the same customer of customer networks 18, so that from a layer-3 perspective customer equipment attached to EVI1 are on VLAN 1 and customer equipment attached to EVI2 are on VLAN2. Taking PE 10A as an example, VLAN1 and VLAN2 are connected to the same VRF 22A through IRB 28A and IRB 30A. From a layer-3 point of view, PEs 10 with NVE functionality appear connected to both VLAN1 and VLAN2 through their respective IRB interfaces. In some examples, one or more IRBs may appear to one or more PEs to be attached to the same EVI. As such, an IRB interface may appear to one or more PEs to be connected to an EVPN. . . “).
In regard to claim 6, the combination of Lin and Singh teaches further comprising: controlling PE1 and PE2 to be dual-homed to a Customer Edge CE1, wherein an Access Circuit AC1 of PE1 and an AC2 of PE2 belong to a same Ethernet segment ESI1 (e.g. VLAN1) (see Fig.1 ¶¶ [0042-0043] “ . . . In operation, each of PEs 10 may configure its respective IRBs to forward multicast traffic to any multicast receivers that are in customer networks directly attached to the respective PE by an attachment circuit, regardless of whether the PE is the PIM-DR. In addition, each respective PE may send PIM Join messages towards the RP or the multicast source, if the respective PE has IGMP/MLD group membership regardless of whether the PE is the DR or IGPM/MLD querier. Furthermore, each of PEs 10 may be configured to forward multicast traffic, which is sent out of IRBs, to local attachment circuits only and not to other remote PEs. In this way, each IRB of a respective PE may operate as a DR (although not formally elected as a PIM-DR) for multicast receivers that are included in a customer network directly coupled to the PE by an attachment circuit. The formally elected PIM-DR is configured to continue operating as a PIM-DR for multicast sources. By implementing the techniques of above, system 2 may perform inter-subnetwork multicast forwarding between multicast receivers and multicast sources and prevent or reduce hair pinning effects within the system. For example, in FIG. 1, multicast source 20A may send multicast traffic to PE 10A using attachment circuit 14A. PE 10A may perform a lookup using VRF 22A to forward network traffic to PEs 10B-10C using VLAN<b>1</b>. In accordance with techniques of the disclosure, IRB 28A also receives the multicast traffic. PE 10A is configured, based on VFR 22A, to forward the multicast traffic across VLAN<b>1</b> and to VLAN<b>2</b> locally to multicast receivers of VLAN<b>2</b> that are included in customer networks directly attached to PE 10A by attachment circuits. For instance, multicast receiver 4B is included in customer network 18B, where customer network 18B is directly coupled to PE 10A by attachment circuit 14B. Accordingly, PE 10A forwards the multicast traffic received at IRB 28A to IRB 30A, thereby causing the multicast traffic to be bridged from VLAN<b>1</b> to VLAN<b>2</b>. IRB 28A then forwards the multicast traffic to multicast receiver 4B. In this way, the multicast traffic need not be bridged at the PIM-DR PE 10C from VLAN<b>1</b> to VLAN<b>2</b> and forwarded back again to PE 10A on VLAN<b>2</b> for forwarding to multicast receiver 4B. As such, the multicast traffic follows a path 31 from multicast source 4A to multicast receiver 4B . . .”)
In regard to claim 7, the combination of Lin and Singh teaches wherein before controlling the VRF table to be registered to the EVPN, such that the EVPN generates the RT5 route corresponding to the service route (see Lin ¶ [0030] as described for the rejection of claim 2 and is incorporated herein) , the method further comprises:
controlling PE1 and PE2 to respectively generate a Route Type-2 (RT2) route for the MAC address M1, and advertise the RT2 route to the EVPN(see Lin ¶ [0025]” . . . As PEs learn the MAC address for customer equipment 4 reachable through local attachment circuits, the PEs 10 utilize 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 that is issuing the route advertisement. In the EVPN implemented in system 2, each of PEs 10 advertises the locally learned MAC addresses to other PEs 10 using a BGP route advertisement, also referred to herein as a “MAC route” or a “MAC Advertisement route.” As further described below, a MAC route typically specifies an individual MAC address of a customer equipment 4 along with additional forwarding information, such as a route descriptor, route target, layer 2 segment identifier, MPLS label, etc. In this way, PEs 10 use BGP to advertise and share the MAC addresses learned when forwarding layer two communications associated with the EVPN. . . .”) ; and
receiving, by PE3, the RT2 route of PE1 and PE2, wherein the RT2 route is respectively advertised by PE1 or PE2 for the BD1 or the BD2, and the RT2 route carries an Ethernet Segment Identifier ESI1 of the ES1 (see Lin ¶ [0031]” . . . PEs 10 and CEs 8 may share NLRI to configure one or more Ethernet segments and share MAC routes that are learned by the respective devices. In general, PEs connected to the same Ethernet segment can automatically discover each other with minimal to no configuration through the exchange of the Ethernet Segment route using BGP. In multi-homed environments EVPN defines a mechanism to signal, to remote PEs, the need to update their forwarding tables upon the occurrence of a failure in connectivity to an Ethernet segment. This is done by having each PE advertise an Ethernet AD Route per Ethernet segment for each locally attached segment which indicates the reachability of the PE in the Ethernet segment. Upon a failure in connectivity to the attached segment, the PE withdraws the corresponding Ethernet AD route by sending an AD route withdrawal message to other PEs. This triggers all PEs that receive the withdrawal to update their next-hop adjacencies for all MAC addresses associated with the Ethernet segment specified by the Ethernet AD route. If no other PEs had advertised an Ethernet AD route for the same segment, then the PE that received the withdrawal simply invalidates the MAC entries for that segment . . .”) ; and
generating, by PE3, a MAC forwarding entry according to the received RT2 route, wherein the MAC forwarding entry implements an Aliasing function via the ESI1 (e.g. associations between MAC addresses and LSP) (see Lin ¶ [0052]” . . . EVPN module 48 executes in the control plane of PE 10A and performs MAC address learning to automatically update portions of forwarding information 56 for each EVI established by PE 10A. In some examples, EVPN module 48 is invoked when PE 10A receives data packets on the LSPs established by router PE 10A for one or more of the PE 10 that are members of an EVI. EVPN module 48 performs MAC address learning using learning module 52 and updates the one of MAC tables 50 to initially record associations between the LSPs connected to PE 10A and the source MAC addresses of the EVPN customer devices from which the data packets were received on the LSPs. For example, the one of MAC tables 50 records LSP identifiers that identify the LSPs connected to PE 10A, and records MAC addresses that identify the source customer devices of the data packets transmitted over the LSPs. In effect, router PE 10A, an L3 routing device (or in some examples, an L2 switching device), learns associations between MAC addresses and LSPs (which are mapped to ports or interfaces), much as an L2 switch learns associations between MAC addresses and ports. Forwarding information 56 may represent a virtual port binding and bridging table. . . .”) .
In regard to claim 8, the combination of Lin and Singh teaches wherein before controlling the VRF table to be registered to the EVPN, such that the EVPN generates the RT5 route corresponding to the service route (see Lin ¶ [0030] as described for the rejection of claim 2 and is incorporated herein), the method further comprises:
generating, by PE1 and PE2, a Route Type-1 (RT1) route for the ESII and an EVPN instance, wherein the RT1 route carries Ethernet Segment (ES) information and label forwarding information (see Lin ¶ [0054]” . . . Forwarding engine 30A receives data packets on inbound links 58 that are destined for one of the PE routers in the EVPN. Forwarding engine 30A determines whether the destination customer MAC address of the data packets is included in the one of MAC tables associated with the EVPN. If the MAC address is included in the one of MAC tables, then PE 10A forwards the data packets to the destination PE router on the LSP associated with the MAC address based on forwarding information 56 associated with the EVPN. If the customer MAC address is not included in the one of MAC tables, PE 10A floods the data packets to all of the PE routers via the LSPs based on forwarding information 56 associated with the EVPN . . .”); and
advertising the RT1 route to the EVPN (see Lin ¶ [0025]” . . . As PEs learn the MAC address for customer equipment 4 reachable through local attachment circuits, the PEs 10 utilize 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 that is issuing the route advertisement. In the EVPN implemented in system 2, each of PEs 10 advertises the locally learned MAC addresses to other PEs 10 using a BGP route advertisement, also referred to herein as a “MAC route” or a “MAC Advertisement route.” As further described below, a MAC route typically specifies an individual MAC address of a customer equipment 4 along with additional forwarding information, such as a route descriptor, route target, layer 2 segment identifier, MPLS label, etc. In this way, PEs 10 use BGP to advertise and share the MAC addresses learned when forwarding layer two communications associated with the EVPN . . .”)
In regard to claim 9, the combination of Lin and Singh teaches wherein after advertising the RT1 route to the EVPN (see Lin ¶ [0025] as described for the rejection of claim 8 and is incorporated herein) , the method further comprises:
receiving, by PE3, the RT1 route advertised by PE1 and PE2 (see Lin Fig. 2 ¶ [0048] “ . . . In the example of FIG. 2, forwarding engine 30A includes forwarding information 56. In accordance with routing information 42, forwarding engine 30A maintains forwarding information 56 that associates network destinations with specific next hops and corresponding interface ports. For example, routing engine 22 analyzes routing information 42 and generates forwarding information 56 in accordance with routing information 42. Forwarding information 56 may be maintained in the form of one or more tables, link lists, radix trees, databases, flat files, or any other data structures. . . .”); and
forming, by PE3, Aliasing with forwarding information of the RT1 route according to the ESI1 in the MAC forwarding entry of the MAC address M1 (see Lin Fig. 2 ¶ [0049] “ . . . Forwarding engine 30A maintains forwarding information 56 for each Ethernet Virtual Instance (EVI) established by PE 10A to associate network destinations with specific next hops and the corresponding interface ports. As described an FIG. 1, an EVI may define one or more Ethernet Segments in an EVPN. In general, when PE 10A receives a data packet on an LSP of a given Ethernet segment via one of inbound links 58, forwarding engine 30A, for example, identifies an associated next hop for the data packet by traversing forwarding information 56 based on information (e.g., labeling information) within the packet. Forwarding engine 30A forwards the data packet on one of outbound links 60 to the corresponding next hop in accordance with forwarding information 56 associated with the Ethernet segment. At this time, forwarding engine 30A may push and/or pop labels from the packet to forward the packet along a correct LSP. . . .”)
In regard to claim 11, Lin teaches A non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when running on a processor (see ¶ [0010] “ . . . a non-transitory computer-readable storage medium is encoded with instructions that, when executed, . . .”), causes the processor to execute following operations:
controlling a Virtual Routing and Forwarding (VRF) table to be registered to an Ethernet Virtual Private Network (EVPN), such that the EVPN generates a Route Type-5 (RT5) route corresponding to a service route, wherein the RT5 route carries an IP prefix Prefix1 (see ¶¶ [0030-0032] as described for the rejection of claim 1 and is incorporated herein) ;
in a case of detecting that an Internet Protocol (IP) address (see ¶ [0030] as described for the rejection of claim 1 and is incorporated herein) of a next hop of the service route is IP1 (see ¶ [0031] as described for the rejection of claim 1 and is incorporated herein), determining a Media Access Control (MAC) address M1 (see ¶ [0024] as described for the rejection of claim 1 and is incorporated herein) , (see ¶ [0025] as described for the rejection of claim 1 and is incorporated herein) ; and
in a case where a Provider Edge PE3 (see Fig. 1 PE 10) receives the RT5 route (see ¶ [0026] as described for the rejection of claim 1 and is incorporated herein), generating a routing table entry according to Prefix1 carried in the RT5 route (see Fig. 1 ¶¶ [0028-0029] as described for the rejection of claim 1 and is incorporated herein) ,
Lin fails to explicitly teach,
However Singh teaches
which is obtained by performing Address Resolution Protocol (ARP) parsing and corresponds to IP1, as an overlay index (e.g. entry for in the address cache) of the RT5 router (see Singh ¶ [0027] as described for the rejection of claim 1 and is incorporated herein)
and looking up a MAC forwarding table from a Supplementary Broadcast Domain (SBD) (see ¶ [0016] as described for the rejection of claim 1 and is incorporated herein) of an IP-VRF instance according to the overlay index M1 of the RT5 route (see Singh ¶ [0027] as described for the rejection of claim 1 and is incorporated herein) ,
wherein the overlay index (e.g. entry of the address cache) is an index that is used for performing, in an overlay network. iterative table-lookup for a packet (see Singh ¶ [0014], ¶ ¶ [0030-0031] as described for the rejection of claim 1 and is incorporated herein).
The motivation to combine Singh with Lin is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 12, Lin teaches An electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute following operations:
controlling a Virtual Routing and Forwarding (VRF) table to be registered to an Ethernet Virtual Private Network (EVPN), such that the EVPN generates a Route Type-5 (RT5) route corresponding to a service route, wherein the RT5 route carries an IP prefix Prefix1(see ¶¶ [0030-0032] as described for the rejection of claim 1 and is incorporated herein) ;
in a case of detecting that an Internet Protocol (IP) address (see ¶ [0030] as described for the rejection of claim 1 and is incorporated herein) of a next hop of the service route is IP1(see ¶ [0031] as described for the rejection of claim 1 and is incorporated herein), determining a Media Access Control (MAC) address M1 (see ¶ [0024] as described for the rejection of claim 1 and is incorporated herein) , (see ¶ [0025] as described for the rejection of claim 1 and is incorporated herein) ; and
in a case where a Provider Edge PE3 (see Fig. 1 PE 10) receives the RT5 route (see ¶ [0026] as described for the rejection of claim 1 and is incorporated herein), generating a routing table entry according to Prefix1 carried in the RT5 route, (see Fig. 1 ¶¶ [0028-0029] as described for the rejection of claim 1 and is incorporated herein),
Lin fails to explicitly teach,
However Singh teaches
which is obtained by performing Address Resolution Protocol (ARP) parsing and corresponds to IP1, as an overlay index (e.g. entry for in the address cache) of the RT5 router (see Singh ¶ [0027] as described for the rejection of claim 1 and is incorporated herein)
and looking up a MAC forwarding table from a Supplementary Broadcast Domain (SBD) (see ¶ [0016] as described for the rejection of claim 1 and is incorporated herein) of an IP-VRF instance according to the overlay index M1 of the RT5 route (see Singh ¶ [0027] as described for the rejection of claim 1 and is incorporated herein)
wherein the overlay index (e.g. entry of the address cache) is an index that is used for performing, in an overlay network, iterative table-lookup for a packet (see Singh ¶ [0014], ¶ ¶ [0030-0031] as described for the rejection of claim 1 and is incorporated herein) .
The motivation to combine Singh with Lin is described for the rejection of claim 1 and is incorporated herein
In regard to claim 13, the combination of Lin and Singh teaches wherein the RT5 route is an EVPN IP prefix route (see Lin ¶ [0030] “ . . . PEs 10 may use control plane signaling with different route types to provision the EVPN service in service provider network 12. EVPN defines BGP Network Layer Reachability Information (NLRI), and in particular, defines different route types. The EVPN NLRI is carried in BGP using BGP Multiprotocol Extensions. Route types include but are not limited to: Ethernet Auto-Discovery (AD) routes, MAC advertisement routes, and Ethernet Segment Routes. AD routes, for example, specify a Route Distinguisher (RD) (e.g., an IP address of an MPLS Edge Switch (MES)), ESI, Ethernet Tag Identifier, and MPLS label. MAC advertisement routes include a RD, ESI, Ethernet Tag Identifier, MAC address and MAC address length, IP address and IP address length, and MPLS label. An Ethernet Segment route includes a Route Distinguisher and Ethernet Segment Identifier. . . .”)
In regard to claim 14, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations before controlling the VRF table to be registered to the EVPN, such that the EVPN generates the RT5 route corresponding to the service route (see Lin ¶ [0030] as described for the rejection of claim 2 and is incorporated herein) :
configuring an EVPN Virtual Private Local Area Network Service (VPLS) Layer-2 instance BD1 (e.g. first L2 domain) for PE1, and configuring an EVPN VPLS Layer-2 instance BD2 (e.g. second L2 domain) for PE2, wherein the BD1 and the BD2 do not import routes of each other (see Lin Fig. 6, ¶¶ [0078-0080] as described for the rejection of claim 2 and is incorporated herein).
In regard to claim 15, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations: controlling the SBD to permit importing of the routes of the BD1 and the BD2 (see Lin Fig. 1, ¶¶ [0039-0040] as described for the rejection of claim 3 and is incorporated herein).
In regard to claim 16, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations: controlling the SBD not to advertise an Inclusive Multicast Ethernet Tag (IMET) route to PE1 or PE2 (see Lin Fig. 5, ¶¶ [0076-0077] as described for the rejection of claim 4 and is incorporated herein).
In regard to claim 17, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations:
controlling an IP address of an Intergraded Routing and Bridging (IRB) interface of the SBD to be in an unnumbered form (see Singh ¶¶ [0032-0034] as described for the rejection of claim 5 and is incorporated herein) , and controlling the IRB interface to be bound to the IP-VRF instance (see Singh Fig. 1 ¶¶ [0032-0034] as described for the rejection of claim 5 and is incorporated herein)
In regard to claim 18, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations: controlling PE1 and PE2 to be dual-homed to a Customer Edge CE1, wherein an Access Circuit AC1 of PE1 and an AC2 of PE2 belong to a same Ethernet segment ESI1 (e.g. VLAN1) (see Fig.1 ¶¶ [0042-0043] as described for the rejection of claim 6 and is incorporated herein)
In regard to claim 19, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations before controlling the VRF table to be registered to the EVPN, such that the EVPN generates the RT5 route corresponding to the service route(see Lin ¶ [0030] as described for the rejection of claim 2 and is incorporated herein) :
controlling PEI and PE2 to respectively generate a Route Type-2 (RT2) route for the MAC address M1, and advertise the RT2 route to the EVPN (see Lin ¶ [0025] as described for the rejection of claim 7 and is incorporated herein); and
receiving, by PE3, the RT2 route of PE1 and PE2, wherein the RT2 route is respectively advertised by PE1 or PE2 for the BD1 or the BD2, and the RT2 route carries an Ethernet Segment Identifier ESI1 of the ES1 (see Lin ¶ [0031] as described for the rejection of claim 7 and is incorporated herein) ; and
generating, by PE3, a MAC forwarding entry according to the received RT2 route, wherein the MAC forwarding entry implements an Aliasing function via the ESI1 (e.g. associations between MAC addresses and LSP) (see Lin ¶ [0052] as described for the rejection of claim 7 and is incorporated herein)
In regard to claim 20, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations before controlling the VRF table to be registered to the EVPN, such that the EVPN generates the RT5 route corresponding to the service route (see Lin ¶ [0030] as described for the rejection of claim 2 and is incorporated herein) :
generating, by PE1 and PE2, a Route Type-1 (RT1) route for the ESI1 and an EVPN instance, wherein the RT1 route carries Ethernet Segment (ES) information and label forwarding information (see Lin ¶ [0054] as described for the rejection of claim 8 and is incorporated herein) ; and
advertising the RT1 route to the EVPN (see Lin ¶ [0025] as described for the rejection of claim 8 and is incorporated herein).
In regard to claim 21, the combination of Lin and Singh teaches wherein the processor is configured to run the computer program to further execute following operations after advertising the RT1 route to the EVPN(see Lin ¶ [0025] as described for the rejection of claim 8 and is incorporated herein) :
receiving, by PE3, the RT1 route advertised by PE1 and PE2 (see Lin Fig. 2 ¶ [0048] as described for the rejection of claim 9 and is incorporated herein); and
forming, by PE3, Aliasing with forwarding information of the RT1 route according to the ESI1 in the MAC forwarding entry of the MAC address M1 (see Lin Fig. 2 ¶ [0049] as described for the rejection of claim 9 and is incorporated herein).
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Primary Examiner, Art Unit 2444