Patent application number | Description | Published |
20090168666 | Implementation of VPNs over a link state protocol controlled Ethernet network - Nodes on a link state protocol controlled Ethernet network implement a link state routing protocol such as IS-IS. Nodes assign an IP address or I-SID value per VRF and then advertise the IP addresses or I-SID values in IS-IS LSAs. When a packet is to be forwarded on the VPN, the ingress node identifies the VRF for the packet and performs an IP lookup in customer address space in the VRF to determine the next hop and the IP address or I-SID value of the VRF on the egress node. The ingress node prepends an I-SID or IP header to identify the VRFs and then creates a MAC header to allow the packet to be forwarded to the egress node on the link state protocol controlled Ethernet network. When the packet is received at the egress node, the MAC header is stripped from the packet and the appended I-SID or IP header is used to identify the egress VRF. A customer address space IP lookup is then performed in the identified VRF on the egress node using the information in the client IP header to determine how to forward the packet. Customer reachability information within a VPN may be exchanged between VRFs using iBGP, or directly by using link state protocol LSAs tagged with the relevant I-SID. | 07-02-2009 |
20100189106 | Method and Apparatus for Enabling Multicast Over Split Multilink Trunking - Multicast traffic may be routed using DVMRP or PIM over a Split MultiLink Trunk (SMLT). Network elements on the split side of the SMLT are interconnected by an Inter-Switch Trunk (IST) to enable them to exchange control messages associated with the multicast. When a control message is received on the IST, the network element will determine if the multicast control message is associated with a normal multicast or is associated with multicast over an SMLT link. Control messages related to SMLT links will be processed as if they were received over the SMLT link rather than the IST link. To prevent traffic from being forwarded by multiple network elements over the SMLT link, data traffic from an IST link may not be transmitted over an SMLT link. Flags are used to indicate whether a link is a SMLT link or regular link. Fast recovery may occur by causing participants to transmit triggered join messages upon recovery from a failure. | 07-29-2010 |
20100316056 | TECHNIQUES FOR ROUTING DATA BETWEEN NETWORK AREAS - Techniques for routing data between network area are disclosed, In one particular exemplary embodiment, the techniques may be realized as a method for routing data between layer 2 network areas of backbone bridges comprising the steps of receiving data at a network element containing an internally terminated Network to Network Interface (NNI) for a plurality of network areas, identifying a destination address associated with the data, determining a network area of the plurality of network areas associated with the data, and performing one or more data flow treatments associated with the data using the internally terminated Network to Network Interface (NNI). | 12-16-2010 |
20100322253 | Method and Apparatus for Simulating IP Multinetting - IP Multinetting on a local area network is simulated by performing VLAN translation at a port connecting to the local area network. This allows IP addresses from multiple subnets to be associated with a single VLAN on the Local Area Network (LAN), while allowing the core switch to process the packets with a one-to-one correspondence between IP Subnet and VLAN. When a packet is received from the local area network at an IP multinetting port, the VLAN ID will be read to determine if the packet contains the IP Multinetting VLAN ID. The IP Subnet address will also be checked to see if the packet is associated with an IP Subnet that is part of the Multinetting. If so, the multinetting VLAN ID will be changed to an IP Subnet specific VLAN ID before the packet is processed by the core switch. In the reverse direction, IP subnet specific VLAN IDs will be translated to the IP Multinetting VLAN ID. | 12-23-2010 |
20100329265 | Method and Apparatus for implementing L2 VPNs on an IP Network - MP-BGP VPN infrastructure based on IETF RFC 4364/2547 is used to configure a layer 2 VPN on an IP network. VRFs for the VPN are configured on Ethernet switches and service IP addresses are associated with each configured VRF. The service IP addresses are exchanged to enable VPN traffic to be encapsulated for transport over the IP network. To enable a L2 VPN to be established on the network, a VPN-VLAN ID will be configured for the L2 VPN and import/export route targets for the VPN-VLAN will be set in each VRF and UNI-VLAN that is part of the VPN. The VPN-VLAN will be announced to all PEs using MP-iBGP with export route targets set for this VPN-VLAN. The PE's control plane learns the VPN-VLAN on a logical port if the import RT matches the export RT received by the MP-iBGP control plane. Once the VPN-VLAN is learned on a logical port, the PE will perform MAC learning on that logical port and treat the logical port as if it were part of the L2 VLAN. | 12-30-2010 |
20110103263 | Implementation of VPNs over a Link State Protocol Controlled Ethernet Network - Nodes on a link state protocol controlled Ethernet network implement a link state routing protocol such as IS-IS. Nodes assign an IP address or I-SID value per VRF and then advertise the IP addresses or I-SID values in IS-IS LSAs. When a packet is to be forwarded on the VPN, the ingress node identifies the VRF for the packet and performs an IP lookup in customer address space in the VRF to determine the next hop and the IP address or I-SID value of the VRF on the egress node. The ingress node prepends an I-SID or IP header to identify the VRFs and then creates a MAC header to allow the packet to be forwarded to the egress node on the link state protocol controlled Ethernet network. When the packet is received at the egress node, the MAC header is stripped from the packet and the appended I-SID or IP header is used to identify the egress VRF. A customer address space IP lookup is then performed in the identified VRF on the egress node using the information in the client IP header to determine how to forward the packet. Customer reachability information within a VPN may be exchanged between VRFs using iBGP, or directly by using link state protocol LSAs tagged with the relevant I-SID. | 05-05-2011 |
20120044937 | Method and Apparatus for Simulating IP Multinetting - IP Multinetting on a local area network is simulated by performing VLAN translation at a port connecting to the local area network. This allows IP addresses from multiple subnets to be associated with a single VLAN on the Local Area Network (LAN), while allowing the core switch to process the packets with a one-to-one correspondence between IP Subnet and VLAN. When a packet is received from the local area network at an IP multinetting port, the VLAN ID will be read to determine if the packet contains the IP Multinetting VLAN ID. The IP Subnet address will also be checked to see if the packet is associated with an IP Subnet that is part of the Multinetting. If so, the multinetting VLAN ID will be changed to an IP Subnet specific VLAN ID before the packet is processed by the core switch. | 02-23-2012 |
20120063451 | SHARED VIRTUAL TUNNELS SUPPORTING MAC LEARNING IN COMMUNICATION NETWORKS - Embodiments herein include systems and methods for providing a mechanism for tunneled data transport within a dual homed access network. A tunnel manager, at a first network connectivity device in a transport network, identifies the transport network configured to interconnect at least two access networks for transporting data traffic between one or more end stations connected to the access networks. The first network connectivity device is coupled to a first access network. The tunnel manager identifies a second network connectivity device. The second network connectivity device is coupled to the first access network to provide the first access network dual homed access to the transport network via the first and second network connectivity devices. The tunnel manager creates a virtual tunnel that connects the first and second network connectivity devices to a third network connectivity device across the transport network. The virtual tunnel defines a same virtual tunnel having multiple paths such that the third network connectivity device learns a single virtual tunnel for device address learning. | 03-15-2012 |
20120170578 | MULTICAST VPN SUPPORT FOR IP-VPN LITE - Techniques disclosed herein include systems and methods for providing multicast Virtual Private Network (VPN) support for IP VPN networks, including IP VPN-lite networks. Such techniques provide multicast VPN capability over an IP unicast core network by creating a multicast service VLAN and IP interface, which is used for multicast control traffic exchange between VPN instances. Multicast VPN data traffic is then carried over unicast IP-in-IP tunnels. A given ingress Provide Edge (PE) replicates the multicast traffic for all receiving egress PEs, and adds control information so that the multicast traffic appears as unicast traffic to the Core network. With such a technique, a given Core network only needs to run an IP unicast that is free of VPN unicast or multicast route or tree information. | 07-05-2012 |
20120233350 | TECHNIQUES FOR ROUTING DATA BETWEEN NETWORK AREAS - Techniques for routing data between network area are disclosed. In one particular exemplary embodiment, the techniques may be realized as a method for routing data between layer 2 network areas of backbone bridges comprising the steps of receiving data at a network element containing an internally terminated Network to Network Interface (NNI) for a plurality of network areas, identifying a destination address associated with the data, determining a network area of the plurality of network areas associated with the data, and performing one or more data flow treatments associated with the data using the internally terminated Network to Network Interface (NNI). | 09-13-2012 |
20130077627 | METHOD AND APPARATUS FOR ROUTING MULTICAST DATA ACROSS MULTIPLE MULTICAST ROUTING DOMAINS CONNECTED BY A SHORTEST PATH BRIDGING (SPB) NETWORK - A method and apparatus for routing multicast data across multiple multicast routing domains connected by a shortest path bridging (SPB) network is presented. A Shortest Path Bridging (SPB) edge router of an SPB network connected to a PIM network is configured as a Rendezvous Point (RP). A message is received at the RP, and in response, the RP forms a first data structure including multicast sender information. The RP floods the SPB network with a second message containing the first data structure, allocates an Identifier (ISID) to the multicast stream, and sends a second data structure with sender information. An edge router with multicast receive interest responds with the second data structure with multicast receive interest information. As a result, a receiver in a second network has knowledge of devices in a first network such that multicast traffic is able to be routed between different networks connected to the SPB network. | 03-28-2013 |
20140347976 | VIRTUAL ROUTER REDUNDANCY PROTOCOL FOR SCALABLE DISTRIBUTED DEFAULT ROUTING GATEWAY - A VRRP router group can operate in either a standard VRRP mode or a distributed gateway mode in which all VRRP routers generate VRRP control packets but transmit those packets only to local access network-side hosts. The rate of VRRP control packet generation may be decreased in the distributed gateway mode relative to the standard mode. Moreover, VRRP router CPUs may cease processing of VRRP control packets in the distributed gateway mode. | 11-27-2014 |
20140369184 | General User Network Interface (UNI) Multi-homing Techniques For Shortest Path Bridging (SPB) Networks - A method, apparatus and computer program product for providing multi-homing techniques for SPB networks is presented. A set of UNI nodes that receive multicast packets are determined based on Backbone Media Access Control-Destination Address (BMAC-DA)/I-Tag Service Identifier (I-SID) of received multicast packets for multicast packets within a transport network. A separate Egress Port Mask is determined for each Backbone-Virtual Local Area Network (B-VLAN) of the transport network, wherein the Egress Port Mask is determined such that only one UNI node of the set of UNI nodes forwards said multicast packets. A set of UNI copies of said multicast packets are filtered out by applying the Egress Port Mask, wherein copies that are not in the Egress Port Mask are dropped. Copies of multicast packets that are not dropped are sent out. | 12-18-2014 |
20150016304 | IMPLEMENTATION OF VPNS OVER A LINK STATE PROTOCOL CONTROLLED ETHERNET NETWORK - Nodes on a link state protocol controlled Ethernet network implement a link state routing protocol such as IS-IS. Nodes assign an IP address or I-SID value per VRF and then advertise the IP addresses or I-SID values in IS-IS LSAs. When a packet is to be forwarded on the VPN, the ingress node identifies the VRF for the packet and performs an IP lookup in customer address space in the VRF to determine the next hop and the IP address or I-SID value of the VRF on the egress node. The ingress node prepends an I-SID or IP header to identify the VRFs and then creates a MAC header to allow the packet to be forwarded to the egress node on the link state protocol controlled Ethernet network. When the packet is received at the egress node, the MAC header is stripped from the packet and the appended I-SID or IP header is used to identify the egress VRF. A customer address space IP lookup is then performed in the identified VRF on the egress node using the information in the client IP header to determine how to forward the packet. Customer reachability information within a VPN may be exchanged between VRFs using iBGP, or directly by using link state protocol LSAs tagged with the relevant I-SID. | 01-15-2015 |
Patent application number | Description | Published |
20080298373 | Secure VLANs - A VLAN is implemented with a logical hub and spoke topology that obviates local switching. Member devices are connected to a hub device such as a router via intermediate devices such as Layer 2 switches that support individual IP subnets within the VLAN. The Layer 2 switch does not allow bridging, so there is no IP subnet broadcast domain. Further, the Layer 2 switch implements only a single logical broadcast uplink port which is connected to the router. The Layer 2 switch also implements only point-to-point downlink ports, i.e., to individual member devices. Consequently, all traffic is forced to flow through the router, e.g., broadcast traffic, multicast traffic and traffic of unknown destination received by the Layer 2 switch from a member device is only flooded to the router, and the router performs intra-subnet routing in addition to routing between subnets and between VLANs. The router subjects all traffic to security measures and provide services including packet inspection, firewall, policing, metering, accounting, anti-virus, marking, filtering and encryption, and thereby reduce or eliminate the drawbacks associated with local switching. | 12-04-2008 |
20090092043 | Providing an abstraction layer in a cluster switch that includes plural switches - In a communications network, a cluster switch is provided, where the cluster switch has plural individual switches. An abstraction layer is provided in the cluster switch, such that an interface having a set of ports is provided to upper layer logic in the cluster switch. The set of ports includes a collection of ports of the individual switches. Control traffic and data traffic are communicated over virtual tunnels between individual switches of the cluster switch, where each virtual tunnel has an active channel and at least one standby channel. | 04-09-2009 |
20090116483 | Supporting BGP Based IP-VPN In A Routed Network - A new type of Provider Edge (PE) device is used to support BGP-based IP-VPNs. Each VRF instance in a PE device is associated with a dedicated IP address (Service IP address). Each service IP address is dedicated to a VRF in a PE device. The service IP address is distributed by BGP for VPN route association. Customer/VRF IP packets can be sent to a VRF instance in the egress PE device using service IP header encapsulation (with IP Destination Address=Service IP address of egress PE's VRF & IP Source Address=Service IP address of ingress PE's VRF). This obviates the need for explicit tunnels in the core. | 05-07-2009 |