Layer 2 virtual private network over PBB-TE/PBT and seamless interworking with VPLS
A Layer 2 Virtual Private Network (L2VPN) system is provided. A Provider Backbone Bridge (PBB) network is provided which comprises a plurality of sites to be connected via a L2VPN. The plurality of sites in the PBB network is connected using a plurality of provider backbone trunks that includes a Provider Backbone Transport (PBT) trunk or a Provider Backbone Bridge Traffic Engineering (PBB-TE) trunk, such that the L2VPN includes the plurality of sites.
Latest Patents:
This application claims priority to U.S. Provisional Patent Application No. 60/920,227 (Attorney Docket No. HAMMP016+) entitled L2VPN OVER PBB/PBT AND SEAMLESS INTERWORKING WITH VPLS filed Mar. 26, 2007 which is incorporated herein by reference for all purposes.
BACKGROUND OF THE INVENTIONCreating a Layer 2 Virtual Private Network (L2VPN) over an Ethernet network is a problem service providers have had for some time. There are a number of solutions that exist or are in the process of being developed, but a number of issues are associated with these solutions. One issue is a slow recovery or convergence time in the event of failure, such as a physical link failure. For example, many solutions create L2VPNs by assigning customers to separate VLANs or service instances as defined in the IEEE 802.1Q, IEEE 802.1ad, or IEEE 802.1ah standards. These solutions rely on a Spanning Tree Protocol (STP) to restore traffic for bridged networks when physical links fail. However, it may take seconds to restore traffic after a link fails when STP is used in common service provider networks. This is not acceptable for service provides that need to provide Carrier Ethernet services with traffic restoration requirements on the order of tens of milliseconds. A typical desired network restoration time is less than 50 ms, which cannot be realistically achieved using STP. Another issue faced by service providers is lack of control over and/or knowledge of the paths or routes between nodes in a L2VPN. For example, one solution called Virtual Private LAN Services (VPLS) operates over Multi Protocol Label Switching (MPLS). The MPLS protocol sets up all routes, but as a result, the service provider does not have complete control over provisioned routes or how new routes will be dynamically chosen after link or node failures. Many service providers come from a telecommunications background where they had full control over and knowledge of routes, as well as backup routes, and may prefer having this knowledge and control. It would be desirable to develop new techniques for creating a L2VPN over an Ethernet network that address these issues.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. A component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
For clarity,
In some embodiments, when transporting the traffic belonging to a customer over a PBT trunk, that customer traffic may be assigned a Service Instance Identifier (I-SID) (107) value to identify the customer. The I-SID is a field of the Ethernet frame as defined in IEEE 802.1ah. Using the I-SID value as customer traffic identification, traffic from more than one customer may be transported over a same PBT trunk. The customer traffic identified by a given I-SID value may also be called a Service Instance and the VSIs belonging to a same L2VPN are then interconnected by a full mesh of Service Instances, which are transported over PBT trunks interconnecting the service provider sites. This is exemplified in
Since PBT is inherently a point-to-point technology, it would be desirable to have convenient tools and/or interfaces to provision routes and/or devices rather than having to manually do this in order to achieve the desired multipoint-to-multipoint L2VPN service. In some embodiments, an external control plane is used. Some examples are described in further detail below. In various embodiments, PBT trunks can be setup using any carrier/service provider PBT control plane, such as GMPLS, a carrier/service provider Operational Support System (OSS), or some other external control plane.
In some embodiments, each PE device maintains a MAC address table associating remote destination MAC addresses with PBT trunks and local destination MAC addresses with local customer facing ports. Maintenance of such a table may follow standard IEEE 802.1 MAC address learning principles.
A VSI is an IETF term for a bridge used to construct a VPLS service over an MPLS network. As defined in IETF RFC 4762 and IETF RFC 4761, a VSI provides standard MAC address learning, filtering, and forwarding actions, as defined in IEEE 802.1D and IEEE 802.1Q standards, which define how learning bridges work. A VSI is a learning bridge and can be used to bridge Ethernet traffic from any source. Thus, Ethernet traffic being carried by a PBT (PBB-TE) trunk can be forwarded by a VSI.
Up till now, creating a L2VPN over a Layer 2 network, e.g., IEEE 802.1ad or IEEE 802.1ah network, has been a problem without a good solution. Prior solutions have been to create L2VPNs by isolating the traffic of different customers using Service VLANs (S-VLANs) in IEEE 802.1ad (also called Q-in-Q) networks and Service Instances Identifiers (I-SID) in Provider Backbone Bridging (PBB) networks, i.e., IEEE 802.1ah networks. However, both 802.ad and 802.1ah require the use of a Spanning Tree Protocol (STP) to resolve loops in the physical topology, and service providers often dislike STP since it results in a network with unpredictable behavior. Service providers may also dislike STP because it may take seconds to restore traffic forwarding after link or node failures. In addition, service providers would often rather use a service with the orderly attributes of PBT, which does not rely on STP. However, PBT trunks by themselves only provide point-to-point services, i.e., PBT by itself does not support L2VPNs, which are multipoint-to-multipoint in nature. Therefore, a solution has been needed for quite some time to provide a L2VPN over an Ethernet network, i.e., a Layer 2 network, but with the same orderly attributes as PBT. By using PBT trunks to interconnect Provider Edges (PEs) over a PBB network, the proposed solution provides a L2VPN service that does not rely on STP and retains the orderly attributes of PBT.
Another prior solution called Virtual Private LAN Services (VPLS) allows for the creation of L2VPNs over MPLS/IP networks. However, VPLS does not work directly over PBB networks or an Ethernet network, since it uses Pseudowires for frame transport among the PEs participating in a L2VPN, i.e., VPLS requires an underlying MPLS network, which some service providers dislike due to its increased operational cost and complexity.
The architecture in
In some embodiments, products that are commercially available from Hammerhead Systems of Mountain View, Calif., are used to implement the techniques disclosed herein. In one example, a L2VPN service over PBB is required by a customer that deploys PBB in the metro core instead of MPLS/IP. In this scenario, the HSX 6000, available from Hammerhead Systems, can be deployed in the aggregation network to take customer traffic into L2VPNs over the PBB metro core network. As the service provider may deploy an MPLS/IP WAN network, the HSX 6000 can also be deployed with an interworking function between L2VPN over PBB (L2VPNoPBB) and VPLS. In this example configuration, the use of the HSX 6000 is extended to many points in the architecture of a L2VPN (see e.g.,
As mentioned with respect to
In one embodiment, for the L2VPN shown in
There are a number of advantages to using an external control plane (e.g. Soapstone) compared with an in-band-distributed control plane (e.g. GMPLS) for provisioning PBT/PBB-TE trunks. An in-band distributed control plane means that routing and switching products are required to include processing engines powerful enough to support a control plane that can handle the load and that can scale with the service. This is a similar problem faced by routers which usually have problems supporting more than a few thousand Pseudowires. As a result, routers and switches usually end up underpowered to handle realistic control plane loads. An external control plane (also called a centralized control plane), eliminates this hardware limitation, since the choice of a processing engine for the control plane is not tied to the development cycle of the router or switch. A separate control plane based on software running on general purpose computing platforms can track Moore's Law improvements in computing capabilities without being limited by past router hardware design points. Scaling is then accomplished by adding additional processing and memory, if and when needed.
An external control plane also eliminates vendor limitations on innovations. With an external control plane, many features can be implemented in the control plane software itself and put into service independent of the forwarding plane hardware. Moreover, this mediates differences in implementation between vendors and enables a seamless service that otherwise would not be possible.
A centralized control plane also enhances robustness, since it isolates the control plane from data plane anomalies and attacks.
Whenever it is said that a frame can be sent (or can only be sent) to A, B and C, where an element in this list is a Pseudowire, a service instance connection, or a customer interface, it is meant the frame can be sent to any subset of the elements in this set. That is the frame can be sent to either A, B, C, A and B, A and C, B and C, or A, B, and C. In other words, the solution supports unicast forwarding (i.e., sending to either A, B, or C), broadcast forwarding (i.e., sending to A, B, and C), and multicast forwarding (i.e., sending to any subset of the list).
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
Claims
1. A method for providing a Layer 2 Virtual Private Network (L2VPN) system, comprising:
- providing a Provider Backbone Bridge (PBB) network comprising a plurality of sites to be connected via a L2VPN; and
- connecting the plurality of sites in the PBB network using a plurality of provider backbone trunks that includes a Provider Backbone Transport (PBT) trunk or a Provider Backbone Bridge Traffic Engineering (PBB-TE) trunk, such that the L2VPN includes the plurality of sites.
2. The method of claim 1, wherein a first L2VPN is provided for a first customer and a second L2VPN is provided for a second customer.
3. The method of claim 2, wherein the first L2VPN is associated with a first plurality of Virtual Switch Instances (VSIs) and the second L2VPN is associated with a second plurality of VSIs.
4. The method of claim 2, wherein the first customer is associated with a first Service Instance and the second customer is associated with a second Service Instance.
5. The method of claim 4, wherein the first Service Instance is defined by one of the following: an I-SID value, a VLAN ID, a stack of VLAN IDs, an I-SID value and a VLAN id, or an I-SID value and a stack of VLAN ids.
6. The method of claim 4, wherein the first Service Instance is unique across a network.
7. The method of claim 2, wherein the first customer is associated with a plurality of customer Service Instances transported over the plurality of provider backbone trunks.
8. The method of claim 3, further comprising connecting the first plurality of VSIs associated with the first L2VPN using a plurality of customer Service Instances transported over the plurality of provider backbone trunks.
9. The method of claim 1 further comprising:
- providing a Virtual Private LAN Services (VPLS) on a Multi Protocol Label Switching (MPLS) network comprising a second plurality of sites; and
- connecting the second plurality of sites using a plurality of Pseudowires, wherein the L2VPN further includes the second plurality of sites.
10. The method of claim 1 further comprising connecting a plurality of L2VPNs over a plurality of PBB metro networks to a Virtual Private LAN Services (VPLS) service over a core MPLS network to build an end-to-end L2VPN service for a customer.
11. The method of claim 1 further comprising connecting a plurality of L2VPNs over a plurality of PBB metro networks to a L2VPN over the PBB network to build an end-to-end L2VPN over PBB for a customer.
12. The method of claim 1 further comprising using a common Virtual Switch Instance (VSI) to connect a L2VPN over the PBB network with a Virtual Private LAN Services (VPLS) service over an Multi Protocol Label Switching (MPLS) network to build an end-to-end L2VPN service for a customer.
13. The method of claim 1 further comprising using a common Virtual Switch Instance (VSI) to connect a L2VPN over a PBB metro network with a L2VPN over a PBB core network to build an end-to-end L2VPN service for a customer.
14. The method of claim 1 further comprising provisioning a plurality of VSIs associated with the plurality of sites.
15. The method of claim 14, wherein provisioning is performed using an external control plane.
16. The method of claim 1 further comprising using a split horizon rule to control distribution of received frames.
17. The method of claim 16, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting a set of one or more Service Instances over the plurality of provider backbone trunks and a set of one or more customer bound interfaces; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame can only be forwarded to the set of customer bound interfaces and (2) in the event a frame is received from one of the set of customer bound interfaces, the received frame can be forwarded as usual as defined by the normal VSI forwarding behavior, i.e., no forwarding restrictions are imposed on the VSI in this case.
18. The method of claim 16, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting the PBB network and an Multi Protocol Label Switching (MPLS) network; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame can only be forwarded to Pseudowires over the MPLS network and a set of customer bound interfaces; (2) in the event a frame is received from a Pseudowire over an MPLS network, the received frame can only be forwarded to a set of Service Instances over the plurality of provider backbone trunks and a set of customer bound interfaces; and (3) in the event a frame is received from a customer bound interface, the received frame can be forwarded as usual as defined by the normal VSI frame forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
19. The method of claim 16, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting a PBB core network having a first set of Service Instances over a first plurality of provider backbone trunks and a PBB metro network having a second set of Service Instances over a second plurality of provider backbone trunks; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from one of a second set of Service Instances over the second plurality of provider ackbone trunks of the PBB metro network, the received frame can only be forwarded to the first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network and a set of customer bound interfaces; (2) in the event a frame is received from one of a first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network, the received frame can only be forwarded to the second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network and a set of customer bound interfaces; and (3) in the event a frame is received from one of a set of customer bound interfaces, the received frame is can be forwarded as usual as defined by the normal VSI frame forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
20. A system for providing a Layer 2 Virtual Private Network (L2VPN) system, comprising:
- a Provider Backbone Bridge (PBB) network comprising a plurality of sites to be connected via a L2VPN; and
- a connector configured to connect the plurality of sites in the PBB network using a plurality of provider backbone trunks that includes a Provider Backbone Transport (PBT) trunk or a Provider Backbone Bridge Traffic Engineering (PBB-TE) trunk, such that the L2VPN includes the plurality of sites.
21. The system of claim 20, wherein a first L2VPN is provided for a first customer and a second L2VPN is provided for a second customer.
22. The system of claim 21, wherein the first L2VPN is associated with a first plurality of Virtual Switch Instances (VSIs) and the second L2VPN is associated with a second plurality of VSIs.
23. The system of claim 21, wherein the first customer is associated with a first Service Instance and the second customer is associated with a second Service Instance.
24. The system of claim 23, wherein the first Service Instance is defined by one of the following: an I-SID value, a VLAN ID, a stack of VLAN IDs, an I-SID value and a VLAN id, or an I-SID value and a stack of VLAN ids.
25. The system of claim 23, wherein the first Service Instance is unique across a network.
26. The system of claim 21, wherein the first customer is associated with a plurality of customer Service Instances transported over the plurality of provider backbone trunks.
27. The system of claim 22, wherein the connector is further configured to connect the first plurality of VSIs associated with the first L2VPN using a plurality of customer Service Instances transported over the plurality of provider backbone trunks.
28. The system of claim 20 further comprising:
- a Virtual Private LAN Services (VPLS) on a Multi Protocol Label Switching (MPLS) network comprising a second plurality of sites; and
- wherein the connector is further configured to connect the second plurality of sites using a plurality of Pseudowires, wherein the L2VPN further includes the second plurality of sites.
29. The system of claim 20, wherein the connector is further configured to connect a plurality of L2VPNs over a plurality of PBB metro networks to a Virtual Private LAN Services (VPLS) service over a core MPLS network to build an end-to-end L2VPN service for a customer.
30. The system of claim 20, wherein the connector is further configured to connect a plurality of L2VPNs over a plurality of PBB metro networks to a L2VPN over the PBB network to build an end-to-end L2VPN over PBB for a customer.
31. The system of claim 20 further comprising a common Virtual Switch Instance (VSI) configured to connect a L2VPN over the PBB network with a Virtual Private LAN Services (VPLS) service over an Multi Protocol Label Switching (MPLS) network to build an end-to-end L2VPN service for a customer.
32. The system of claim 20 further comprising a common Virtual Switch Instance (VSI) configured to connect a L2VPN over a PBB metro network with a L2VPN over a PBB core network to build an end-to-end L2VPN service for a customer.
33. The system of claim 20 further comprising a controller configured to provision a plurality of VSIs associated with the plurality of sites.
34. The system of claim 33, wherein the controller includes an external control plane.
35. The system of claim 20, wherein a split horizon rule is used to control distribution of received frames.
36. The system of claim 35, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting a set of one or more Service Instances over the plurality of provider backbone trunks and a set of one or more customer bound interfaces; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame can only be forwarded to the set of customer bound interfaces and (2) in the event a frame is received from one of the set of customer bound interfaces, the received frame can be forwarded as usual as defined by the normal VSI forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
37. The system of claim 35, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting the PBB network and an Multi Protocol Label Switching (MPLS) network; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame can only be forwarded to Pseudowires over the MPLS network and a set of customer bound interfaces; (2) in the event a frame is received from a Pseudowire over an MPLS network, the received frame can only be forwarded to a set of Service Instances over the plurality of provider backbone trunks and a set of customer bound interfaces; and (3) in the event a frame is received from a customer bound interface, the received frame can be forwarded as usual as defined by the normal VSI frame forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
38. The system of claim 35, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting a PBB core network having a first set of Service Instances over a first plurality of provider backbone trunks and a PBB metro network having a second set of Service Instances over a second plurality of provider backbone trunks; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from one of a second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network, the received frame can only be forwarded to the first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network and a set of customer bound interfaces; (2) in the event a frame is received from one of a first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network, the received frame can only be forwarded to the second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network and a set of customer bound interfaces; and (3) in the event a frame is received from one of a set of customer bound interfaces, the received frame is can be forwarded as usual as defined by the normal VSI frame forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
39. A computer program product for providing a Layer 2 Virtual Private Network (L2VPN) system, the computer program product being embodied in a computer readable storage medium and comprising computer instructions for:
- providing a Provider Backbone Bridge (PBB) network comprising a plurality of sites to be connected via a L2VPN; and
- connecting the plurality of sites in the PBB network using a plurality of provider backbone trunks that includes a Provider Backbone Transport (PBT) trunk or a Provider Backbone Bridge Traffic Engineering (PBB-TE) trunk, such that the L2VPN includes the plurality of sites.
40. The computer program product of claim 39, wherein a first L2VPN is provided for a first customer and a second L2VPN is provided for a second customer.
41. The computer program product of claim 40, wherein the first L2VPN is associated with a first plurality of Virtual Switch Instances (VSIs) and the second L2VPN is associated with a second plurality of VSIs.
42. The computer program product of claim 40, wherein the first customer is associated with a first Service Instance and the second customer is associated with a second Service Instance.
43. The computer program product of claim 42, wherein the first Service Instance is defined by one of the following: an I-SID value, a VLAN ID, a stack of VLAN IDs, an I-SID value and a VLAN id, or an I-SID value and a stack of VLAN ids.
44. The computer program product of claim 42, wherein the first Service Instance is unique across a network.
45. The computer program product of claim 40, wherein the first customer is associated with a plurality of customer Service Instances transported over the plurality of provider backbone trunks.
46. The computer program product of claim 41, further comprising computer instructions for connecting the first plurality of VSIs associated with the first L2VPN using a plurality of customer Service Instances transported over the plurality of provider backbone trunks.
47. The computer program product of claim 39 further comprising computer instructions for:
- providing a Virtual Private LAN Services (VPLS) on a Multi Protocol Label Switching (MPLS) network comprising a second plurality of sites; and
- connecting the second plurality of sites using a plurality of Pseudowires, wherein the L2VPN further includes the second plurality of sites.
48. The computer program product of claim 39 further comprising computer instructions for connecting a plurality of L2VPNs over a plurality of PBB metro networks to a Virtual Private LAN Services (VPLS) service over a core MPLS network to build an end-to-end L2VPN service for a customer.
49. The computer program product of claim 39 further comprising computer instructions for connecting a plurality of L2VPNs over a plurality of PBB metro networks to a L2VPN over the PBB network to build an end-to-end L2VPN over PBB for a customer.
50. The computer program product of claim 39 further comprising computer instructions for using a common Virtual Switch Instance (VSI) to connect a L2VPN over the PBB network with a Virtual Private LAN Services (VPLS) service over an Multi Protocol Label Switching (MPLS) network to build an end-to-end L2VPN service for a customer.
51. The computer program product of claim 39 further comprising computer instructions for using a common Virtual Switch Instance (VSI) to connect a L2VPN over a PBB metro network with a L2VPN over a PBB core network to build an end-to-end L2VPN service for a customer.
52. The computer program product of claim 39 further comprising computer instructions for provisioning a plurality of VSIs associated with the plurality of sites.
53. The computer program product of claim 52, wherein provisioning is performed using an external control plane.
54. The computer program product of claim 39 further comprising computer instructions for using a split horizon rule to control distribution of received frames.
55. The computer program product of claim 54, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting a set of one or more Service Instances over the plurality of provider backbone trunks and a set of one or more customer bound interfaces; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame can only be forwarded to the set of customer bound interfaces and (2) in the event a frame is received from one of the set of customer bound interfaces, the received frame can be forwarded as usual as defined by the normal VSI forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
56. The computer program product of claim 54, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting the PBB network and an Multi Protocol Label Switching (MPLS) network; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame can only be forwarded to Pseudowires over the MPLS network and a set of customer bound interfaces; (2) in the event a frame is received from a Pseudowire over an MPLS network, the received frame can only be forwarded to a set of Service Instances over the plurality of provider backbone trunks and a set of customer bound interfaces; and (3) in the event a frame is received from a customer bound interface, the received frame can be forwarded as usual as defined by the normal VSI frame forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
57. The computer program product of claim 54, wherein:
- the split horizon rule is associated with a first Virtual Switch Instance (VSI) connecting a PBB core network having a first set of Service Instances over a first plurality of provider backbone trunks and a PBB metro network having a second set of Service Instances over a second plurality of provider backbone trunks; and
- the split horizon rule restricts the normal VSI frame forwarding/distribution of received frames such that: (1) in the event a frame is received from one of a second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network, the received frame can only be forwarded to the first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network and a set of customer bound interfaces; (2) in the event a frame is received from one of a first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network, the received frame can only be forwarded to the second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network and a set of customer bound interfaces; and (3) in the event a frame is received from one of a set of customer bound interfaces, the received frame is can be forwarded as usual as defined by the normal VSI frame forwarding behavior, i.e., no forwarding restrictions are imposed to the VSI in this case.
Type: Application
Filed: Mar 25, 2008
Publication Date: Oct 9, 2008
Patent Grant number: 8018880
Applicant:
Inventors: Norival R. Figueira (Campbell, CA), Richard D. Gitlin (Little Silver, NJ)
Application Number: 12/079,413
International Classification: H04L 12/66 (20060101);