Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050220096 A1
Publication typeApplication
Application numberUS 10/818,685
Publication dateOct 6, 2005
Filing dateApr 6, 2004
Priority dateApr 6, 2004
Also published asCA2560702A1, CN1938997A, CN1938997B, DE602005017882D1, EP1735961A1, EP1735961B1, US9356862, US20130176906, US20150016262, WO2005099183A1
Publication number10818685, 818685, US 2005/0220096 A1, US 2005/220096 A1, US 20050220096 A1, US 20050220096A1, US 2005220096 A1, US 2005220096A1, US-A1-20050220096, US-A1-2005220096, US2005/0220096A1, US2005/220096A1, US20050220096 A1, US20050220096A1, US2005220096 A1, US2005220096A1
InventorsRobert Friskney, Nigel Bragg, Simon Parry, Peter Ashwood-Smith, David Allan
Original AssigneeRobert Friskney, Nigel Bragg, Simon Parry, Peter Ashwood-Smith, Allan David I
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Traffic engineering in frame-based carrier networks
US 20050220096 A1
Abstract
The invention relates to enabling traffic engineering in frame-based networks such as Ethernet networks. There is described a method of and connection controller for establishing connections (76, 77) in a frame-based communications network comprising nodes (71-75 and 78) such as Ethernet switches. The connections are established by configuring, in various of the nodes, mappings for forwarding data frames, such as Ethernet frames. The mappings are from a combination of a) a destination address corresponding to a destination node (73) of the connection and b) an identifier, such as a VLAN tag. The mappings are to selected output ports of the various nodes. By using the combination of destination address AND identifier, the mappings enable data frames belonging to different connections (76, 77) to be forwarded differentially (ie forwarded on different output ports) at a node (75) despite the different connections having the same destination node. This enables flexibility in routing connections—ie the ability to perform traffic engineering.
Images(12)
Previous page
Next page
Claims(29)
1. A method of establishing connections in a frame-based network, the method comprising the step of:
configuring, in one or more nodes of the network, first mappings for use in forwarding data frames, the first mappings being from a combination of:
a) a first destination address corresponding to a first destination node of the network, and
b) a first identifier,
the first mappings being to a selected output port of, or to respective selected output ports of each of, the one or more nodes, thereby establishing at least part of a first connection through the one or more nodes to the first destination node.
2. A method according to claim 1 comprising the further step of:
configuring, in at least one of the nodes, a second mapping for use in forwarding data frames, the second mapping being from a combination of:
a) a second destination address corresponding to a second destination node of the network, and
b) a second identifier,
the second mapping being to a selected output port of the at least one node, thereby establishing at least part of a second connection through the at least one node to the second destination node,
the selected output ports of the at least one node being different for the first and second mappings, thereby enabling, at the at least one node,
differential forwarding of data frames associated with the first and second connections.
3. A method according to claim 2, wherein the first and second destination addresses and the first and second destination nodes are the same.
4. A method according to claim 2, wherein the first and second identifiers are the same.
5. A method according to claim 2, wherein the at least one node associates data frames with one of the first and second connections in dependence on a destination address and identifier of the frame.
6. A method according to claim 1, wherein the network is an Ethernet network and the one or more nodes are Ethernet switches.
7. A method according to claim 6, wherein the identifier is a VLAN tag.
8. A method according to claim 1, wherein the configuration is performed by a control plane of the network.
9. A method according to claim 8, wherein the control plane is ASON/ASTN.
10. A method according to claim 1, wherein the network is at least partially meshed.
11. A frame-based communications network comprising one or more nodes arranged to perform the method of claim 1.
12. Software arranged to perform the method of claim 1.
13. A connection controller for establishing connections in a frame-based network, the connection controller comprising:
a signal generator capable of generating a first signal for configuring, in a transport node of the network, a first mapping for use in forwarding data frames, the first mapping being from a combination of:
a) a first destination address corresponding to a first destination node of the network, and
b) a first identifier,
the first mapping being to a selected output port of the transport node, the first signal thereby establishing at least part of a first connection through the transport node to the first destination node.
14. A connection controller according to claim 13, wherein the signal generator is capable of generating a second signal for configuring, in the transport node of the network, a second mapping for use in forwarding data frames, the second mapping being from a combination of:
a) a second destination address corresponding to a second destination node of the network, and
b) a second identifier,
the second mapping being to a selected output port of the transport node, the second signal thereby establishing at least part of a second connection through the transport node to the second destination node,
the selected output ports of the transport node being different for the first and second mappings, the first and second signals thereby enabling, at the transport node, differential forwarding of data frames associated with the first and second connections.
15. A connection controller according to claim 14, wherein the first and second destination addresses and the first and second destination nodes are the same.
16. A connection controller according to claim 14, wherein the first and second identifiers are the same.
17. A connection controller according to claim 13, wherein the network is an Ethernet network and the transport node is an Ethernet switch.
18. A connection controller according to claim 17, wherein the identifier is a VLAN tag.
19. A connection controller according to claim 13, wherein the network is at least partially meshed.
20. A connection controller according to claim 13 physically co-located with the transport node.
21. A frame-based network comprising the connection controller of claim 13.
22. A method of establishing a connection in a frame-based network, the method comprising the steps of:
configuring forwarding information in a plurality of nodes of the network the forwarding information enabling the nodes to forward data frames in dependence on a combination of a destination address and an identifier of the data frames.
23. A method of data traffic engineering in a frame-based network, the method comprising the following steps:
establishing a first and second connections in the network passing through a common switching node of the network,
configuring the switching node to forward data frames differently in dependence on differences in either a destination address or an identifier of the data frames, thereby enabling data traffic engineering.
24. A method of establishing connections in a frame-based network, the method comprising the step of:
configuring, in each of a first plurality of nodes of the network, a first forwarding mapping from a first combination of a destination address and an identifier to a selected output port of a respective node of the first plurality of nodes.
25. A method according to claim 24 comprising the further step of:
configuring, in at least one of the first plurality of nodes, a second forwarding mapping from a second combination of a destination address and an identifier to a selected output port of the at least one node,
wherein the first and second mappings at the at least one node respectively map to different output ports of the at least one node.
26. A connection controller for establishing connections in a frame-based network, the connection controller being arranged to configure a first forwarding mapping in a transport node, the first mapping being from a first combination of a destination address and an identifier to a first output port of the transport node.
27. A connection controller according to claim 26, the connection controller being arranged to configure a second forwarding mapping in the transport node, the second mapping being from a second, different combination of a destination address and an identifier to a second, different output port of the transport node, thereby to enable differential forwarding of data frames by the transport node in dependence on a combination of a destination address and an identifier of the data frames.
28. A method of forwarding data frames in a frame-based network, the method comprising the steps of:
establishing a first connection in the network, the first connection being associated with a first combination of a destination address and an identifier, and
forwarding data frames in the network in dependence on a combination of a destination address and an identifier of the data frames.
29. A method according to claim 28, wherein the first connection is routed through a switching node having different first and second output ports connected to other nodes of the network, the method comprising the further steps of:
establishing a second connection in the network through the switching node, the second connection being associated with a second combination of a destination address and an identifier, different to the first combination, and
the switching node forwarding data frames having the first combination of a destination address and an identifier on the first output port and forwarding data frames having the second combination of a destination address and an identifier on the second output port.
Description
    FIELD OF THE INVENTION
  • [0001]
    The present invention relates to methods of, software for and apparatus for enabling traffic engineering in carrier networks.
  • BACKGROUND TO THE INVENTION
  • [0002]
    For many years now, telecommunications carriers have been deploying packet-switched networks in place of circuit-switched networks for reasons of efficiency and economy. Packet-switched networks such as Internet Protocol (IP) or Ethernet networks are intrinsically connectionless in nature and as a result suffer from Quality of Service (QoS) problems. Customers value services which are guaranteed in terms of bandwidth and QoS.
  • [0003]
    Carriers may use Multi-Protocol Label Switching (MPLS) over a layer 2 network to create connection-oriented label switched paths (or tunnels) across the intrinsically connectionless network, and thereby to provide guaranteed QoS and bandwidth services to customers. However, MPLS is a relatively unstable standard and carriers desire an alternative.
  • [0004]
    It is desired to use Ethernet switches in carrier's networks. Use of Ethernet switches in carrier's networks would have the advantages of interoperability (mappings between Ethernet and other frame/packet/cell data structures such as IP and ATM are well known) and economy (Ethernet switches are relatively inexpensive compared to IP routers, for example).
  • [0005]
    However, the behaviour of conventional switched Ethernet networks is incompatible with carriers' requirements for providing guaranteed services to customers. Carriers need networks to be meshed for load balancing and resiliency—ie there must be multiple paths across it—and the ability to perform traffic engineering—ie the ability of the network operator to control the provision of explicitly routed variable bandwidth connections (or tunnels) through which traffic may be directed.
  • [0006]
    In contrast, conventional Ethernet networks must be simply-connected—ie there must be one and only one path between each and every node of the network. As a consequence, conventional Ethernet networks do not have support for network-wide load balancing, suffer from resiliency problems and cannot support traffic engineering.
  • [0007]
    Spanning tree protocols are known which enable a physically meshed Ethernet network to be logically transformed into a simply-connected network by detecting physical loops and logically disabling connections to break up the loops. Spanning tree protocols are also known which are able to detect failure of a physical connection (thereby partitioning the fully-connected network) and automatically restore one or more previously-disabled physical connections so as to re-connect the network. This provides a degree of resiliency. However, carriers are capable of and so desire to plan their network traffic routes to achieve much higher resiliency, flexibility and efficiency than spanning tree can achieve. This routing can most easily be achieved by segregating the traffic into connections whose routes are determined as part of this planning process.
  • [0008]
    Virtual Bridged LANs (or VLANs) are described in the Institute of Electrical and Electronics Engineers (IEEE) standard 802.1Q, 2003 Edition. FIG. 1 shows a conventional VLAN 10 split up into a plurality of component LANs 12 and connected via VLAN-aware Media Access Control (MAC) bridges 14. Component LANs 12 are typically provided for different communities of interest, such as users sharing a common server or having common network protocol requirements. Unique identifiers (VLAN tags or VLAN IDs) are used to identify each component LAN. Broadcast traffic is broadcast only within component LANs. This helps to overcome the scalability issues of the Ethernet by separating the whole VLAN 10 into smaller broadcast domains. VLAN tags are used to distinguish between traffic for different component LANs when forwarding traffic on shared links between MAC bridges.
  • [0009]
    The Internet Engineering Task Force (IETF) has published an Internet Draft referred to as draft-kawakami-mpls-lsp-vlan-00:txt. This document describes the use of VLAN tags for label switching across Ethernet networks in a manner similar to use of MPLS labels for label switching over MPLS networks—VLAN tags are used as labels to mark traffic at an ingress point of a label switched path (LSP) as belonging to a Layer 2 tunnel, and VLAN-aware Ethernet switches in the network act as a VLAN label switched routers. Connections are formed using one or more LSPs. Intermediate nodes along the connection may optionally swap the inbound label to a different outbound label.
  • [0010]
    One problem with the method proposed in draft-kawakami-mpls-lsp-vlan-00.txt is that a maximum of 4094 unique VLAN tags are definable in 802.1Q compliant equipment. This limits the flexibility in and increases the complexity of provisioning connections across the network. Another problem is that connections may not easily be re-routed once provisioned without creating transitory loops.
  • [0011]
    Another problem is that the Frame Check Sequence (FCS) in Ethernet frames is computed over both the payload and header portions of the frame. Thus, with the method proposed in draft-kawakami-mpls-lsp-vlan-00.txt, every time a VLAN tag (ie a label) is swapped at the ingress or egress point of a LSP, the FCS needs to be recomputed since the VLAN tag will have changed. This requires performing a computation function over the entire Ethernet frame. Moreover, during the interval from when the original FCS is removed and the new FCS added, the frame is vulnerable to corruption without the protection of any FCS.
  • [0012]
    Another problem with the ‘label-swapping’ approach proposed in draft-kawakami-mpls-lsp-vlan-00.txt is that it requires a “chain of correctness” in that forwarding relies on each local label-forwarded link on the LSP being correct, whereas conventional Ethernet which uses globally unique address information to perform forwarding. More importantly, from a practical perspective, ‘label-swapping’ behaviour represents a significant change from conventional Ethernet switch functionality, and current telecommunications standards.
  • SUMMARY OF THE INVENTION
  • [0013]
    The present invention relates to enabling traffic engineering in frame-based networks such as Ethernet networks. The term traffic engineering is used broadly in the present document to refer to functions for maintaining the quality of service of the customers' connections while permitting the owner to operate their network efficiently. Examples of this are ensuring that no link is over-loaded, load-balancing the connections evenly across the network, re-equalizing the load on the network by re-routing some existing connections, establishing protection mechanisms, performing traffic restoration actions, and so on.
  • [0014]
    According to the present invention, connections are established in the carrier network by configuring, in one or more network nodes, mappings for forwarding data frames such as Ethernet frames. The mappings are from a combination of a) a destination address corresponding to a destination node of a connection, such as a MAC address, and b) an identifier, such as a VLAN tag. The mappings are to selected output ports of the one or more nodes. By using the combination of destination address AND identifier, the mappings enable data frames belonging to different connections to be forwarded differentially (ie forwarded on different output ports) despite the different connections potentially having the same destination node. This enables flexibility in routing connections—eg the ability to perform traffic engineering. The reader should note that the term address is used in this document to denote any means of identifying a network node or an ingress or egress interface of a network node.
  • [0015]
    According to a first aspect of the present invention, there is provided a method of establishing connections in a frame-based network, the method comprising the step of configuring, in one or more nodes of the network, first mappings for use in forwarding data frames, the first mappings being from a combination of a first destination address corresponding to a first destination node of the network, and a first identifier, the first mappings being to a selected output port of, or to respective selected output ports of each of, the one or more nodes, thereby establishing at least part of a first connection through the one or more nodes to the first destination node.
  • [0016]
    Advantageously, the present invention enables connections to be established in a frame-based network in a highly flexible manner enabling network-wide traffic engineering. Furthermore, the specific problems inherent in the method proposed in draft-kawakami-mpls-lsp-vlan-00.txt (processing overhead and vulnerability of frames to corruption) are overcome since no label swapping is performed.
  • [0017]
    In one embodiment, the method of the present invention includes configuring, in at least one of the nodes, a second mapping for use in forwarding data frames, the second mapping being from a combination of: a second destination address corresponding to a second destination node of the network, and a second identifier, the second mapping being to a selected output port of the at least one node, thereby establishing at least part of a second connection through the at least one node to the second destination node, the selected output ports of the at least one node being different for the first and second mappings, thereby enabling, at the at least one node, differential forwarding of data frames associated with the first and second connections.
  • [0018]
    Thus, advantageously, two connections may be established which converge in route at an intermediate node and then diverge again, for example.
  • [0019]
    In one embodiment, the first and second destination addresses and the first and second destination nodes are the same. Thus, for example, two connections may be established which converge at an intermediate node and then diverge, despite having the same destination node. This enables greater flexibility in setting up connections.
  • [0020]
    In one embodiment, the first and second identifiers are the same. Thus, for example, two connections may be established which converge at an intermediate node and then diverge, despite using the same identifier. Thus, limitations on the number of values identifiers can take do not significantly reduce flexibility in traffic engineering.
  • [0021]
    Preferably, the network is an Ethernet network and the one or more nodes are Ethernet switches. Preferably, the identifier is a VLAN tag. Advantageously, this enables traffic engineered carrier networks to be deployed using conventional and relatively inexpensive VLAN-aware Ethernet switches, albeit configured in an entirely novel and inventive manner.
  • [0022]
    In one embodiment, the configuration is performed by a control plane of the network. Thus, carriers have direct control over the establishment of traffic engineering connections in the network. Preferably, the control plane is ASON/ASTN.
  • [0023]
    A frame-based communications network comprising one or more nodes arranged to perform the method of the first aspect of the present invention set out above is also provided.
  • [0024]
    Software arranged to perform the method of the first aspect of the present invention set out above is also provided.
  • [0025]
    According to a second aspect of the present invention, there is provided a connection controller for establishing connections in a frame-based network, the connection controller comprising: a signal generator capable of generating a first signal for configuring, in a transport node of the network, a first mapping for use in forwarding data frames, the first mapping being from a combination of: a first destination address corresponding to a first destination node of the network, and a first identifier, the first mapping being to a selected output port of the transport node, the first signal thereby establishing at least part of a first connection through the transport node to the first destination node.
  • [0026]
    According to a third aspect of the present invention, there is provided a method of establishing a connection in a frame-based network, the method comprising the steps of: configuring forwarding information in a plurality of nodes of the network the forwarding information enabling the nodes to forward data frames in dependence on a combination of a destination address and an identifier of the data frames.
  • [0027]
    According to a fourth aspect of the present invention, there is provided a method of data traffic engineering in a frame-based network, the method comprising the following steps: establishing a first and second connections in the network passing through a common switching node of the network, configuring the switching node to forward data frames differently in dependence on differences in either a destination address or an identifier of the data frames, thereby enabling data traffic engineering.
  • [0028]
    According to a fifth aspect of the present invention, there is provided a method of establishing connections in a frame-based network, the method comprising the step of: configuring, in each of a first plurality of nodes of the network, a first forwarding mapping from a first combination of a destination address and an identifier to a selected output port of a respective node of the first plurality of nodes.
  • [0029]
    According to a sixth aspect of the present invention, there is provided a connection controller for establishing connections in a frame-based network, the connection controller being arranged to configure a first forwarding mapping in a transport node, the first mapping being from a first combination of a destination address and an identifier to a first output port of the transport node.
  • [0030]
    According to a seventh aspect of the present invention, there is provided a method of forwarding data frames in a frame-based network, the method comprising the steps of: establishing a first connection in the network, the first connection being associated with a first combination of a destination address and an identifier, and forwarding data frames in the network in dependence on a combination of a destination address and an identifier of the data frames.
  • [0031]
    Further aspects of the present invention are set out in the appended claims. Further advantages of the present invention will be apparent from the following description.
  • [0032]
    In order to show how the invention may be carried into effect, embodiments of the invention are now described below by way of example only and with reference to the accompanying figures in which:
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0033]
    FIG. 1 shows a conventional Virtual Bridged LAN;
  • [0034]
    FIG. 2 shows an arrangement of Ethernet switches forming a carrier network according to the present invention;
  • [0035]
    FIG. 3 shows a control plane/transport plane architecture for controlling the Ethernet carrier network of FIG. 1 according to the present invention;
  • [0036]
    FIG. 4 shows the carrier Ethernet network of FIG. 1 arranged to provide connectivity between customer sites according to the present invention;
  • [0037]
    FIG. 5 shows how nodes of the control plane interact with Ethernet switches of the transport plane to establish a connection across carrier network according to the present invention;
  • [0038]
    FIG. 6 is a flow diagram showing the use of VLAN tag and destination address to differentiate forwarding of data traffic in different connections across the carrier network, according to the present invention;
  • [0039]
    FIG. 7 shows an example of differential forwarding for two traffic flows having the same source and destination provider edge nodes but different VLAN tags according to the present invention;
  • [0040]
    FIG. 8 shows an example of differential forwarding for two traffic flows having the same source provider edge nodes and VLAN tags but different destination provider edge nodes according to the present invention;
  • [0041]
    FIG. 9 shows an example of converged routing for two traffic flows having the same destination provider edge node and VLAN tags but different source provider edge node according to the present invention;
  • [0042]
    FIG. 10 shows a sparse mode of broadcast operation for customer VPNs provisioned across a carrier network, according to the present invention.
  • [0043]
    FIG. 11 shows a dense mode of broadcast operation for customer VPNs provisioned across a carrier network, according to the present invention.
  • DETAILED DESCRIPTION OF INVENTION
  • [0044]
    Embodiments of the present invention are described below by way of example only. These examples represent the best ways of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved.
  • [0045]
    To support guaranteed QoS to customers, what is required is:
      • 1) an at least partially meshed carrier network;
      • 2) the ability to establish explicitly routed connections across the carrier network between any two edge nodes (traffic engineering); and
      • 3) the ability to enforce any bandwidth restrictions applied to the connections.
  • [0049]
    The present invention is primarily concerned with enabling requirements 1) and 2) above in frame-based networks such as Ethernet networks. Requirement 3) may be achieved using conventional mechanisms such as admission control at the ingress nodes of connections (trusted-edge policing).
  • [0050]
    FIG. 2 shows an arrangement of Ethernet switches and communications links forming a carrier network according to the present invention. Carrier network cloud 20 comprises Ethernet switches 22 a, 22 b, 24 a, 24 b, 26 and 28. Ethernet switches 22 a, 22 b and 26 are located at the edges of carrier network 20, whereas Ethernet switches 24 a, 24 b, and 28 are located in the core network. Communications links (shown as straight lines in FIG. 2) are provided between Ethernet switches 22 a, 22 b, 24 a, 24 b, 26 and 28. These communications links may be relatively long distance links over optical equipment such as SONET/SDH equipment with Ethernet interfaces using Generic Framing Procedure (GFP) (ITU-T Recommendation G.7041/NY.1303).
  • [0051]
    Note that core network switches 24 a, 24 b, and 28 are fully-meshed—ie there is a direct communications link connecting each core network switch 24 a, 24 b, and 28 to each other. Edge network switches 22 a, 22 b and 26 are not fully-meshed but have at least one direct communication link to communications link to a core network switch 26. The reader will appreciate that the particular network arrangement described is exemplary. In general, carrier networks may be implemented with virtually any number of Ethernet switches which, according to the present invention, may be connected in a fully-meshed or partially-meshed manner.
  • [0052]
    FIG. 4 shows how a carrier Ethernet network may provide connectivity between customer sites according to the present invention. Three customers having respective pairs of geographically distant Ethernet switches (40 a and 40 b, 42 a and 42 b, and 44 a and 44 b) are shown connected to carrier network 20 via edge Ethernet switches 22 a and 22 b respectively. The communications links between edge switches 22 a and 22 b and customer switches 40 a, 40 b, 42 a, 42 b, 44 a, and 44 b may be dedicated links such as T1 leased lines or access links such as digital Subscriber Lines (DSLs).
  • [0053]
    Carrier edge switches 22 a, 22 b and 26 may be logically separated according to Nortel Network's Logical Provider Edge (LPE) architecture. Each carrier edge switch may thus be logically separated into a single Provider Edge- (PE-) Core and one or more PE-Edge functions. The PE-Edge is the ingress/egress point at which customer traffic enters or leaves the provider network—ie carrier network 20. The PE-Core encapsulates incoming Ethernet traffic from the customer using Media Access Control (MAC) in MAC encapsulation and forwards the encapsulated traffic across the carrier network. Similarly the PE-Core decapsulates (strips) outgoing Ethernet traffic and forwards the stripped traffic on to the customer via the appropriate PE-Edge. VLAN tags are used to provide customer separation at the PE-Core with each different customer site connected to each edge switch having a unique VLAN tag. Stacked VLAN (ie VLAN in VLAN encapsulation) may be used to protect any VLAN tags used by the customer traffic.
  • [0054]
    For example, customer switch 42 a may send Ethernet traffic over communications link 46 a to PE-Edge of edge switch 22 a. PE-Core of edge switch 22 a encapsulates each Ethernet frame in a further Ethernet frame using the MAC address of edge switch 22 a as the source address and the MAC address of the appropriate egress point—in this case edge switch 22 b—as the destination address. The encapsulated traffic is forwarded across a connection established over communications links 48 of carrier network 20 to edge switch 22 b. Note that connections will typically be trunked in the sense that traffic from multiple customers will be routed through the same connection. At the PE-Core of edge switch 22 b, the original frames are stripped out and sent over communications link 46 b via PE-Edge of edge switch 22 b to customer switch 42 b.
  • [0055]
    The reader will appreciate that in alternative embodiments of the present invention the PE-Edge may also be physically separated from the PE-Core and may reside at customer premises whereas the PE-Core resides at a central office or Point of Presence (PoP) of the carrier. The reader will also appreciate that other edge switches 26 will have connections to customer sites and that customers may have be provided with connectivity between two or more geographically distant sites over carrier network 20.
  • [0056]
    It will now be described how carrier network 20 is arranged to establish connections through which to forward encapsulated Ethernet traffic. A connection may be defined as an entity configured in a network which provides transport of data from a source node to one or more sink nodes.
  • [0057]
    As described above, carrier network 20 must be at least partially-meshed—ie there must be multiple paths between at least some, and preferably all, nodes of the network. Thus, as will be explained below, Ethernet MAC address auto learning functionality should preferably be at least partially deactivated.
  • [0058]
    On start-up (or on re-start), conventional switched Ethernet networks behave like a “classic” Ethernet Local Area Networks (LANs) in that every Ethernet frame is broadcast across the entire network. Thus, every switch, receiving an Ethernet frame on one port, broadcasts the frame out on every other port. The process repeats as the frame is received by other switches thus broadcasting the frame across the entire network.
  • [0059]
    MAC address auto-learning functionality is provided to improve efficiency in switched Ethernet networks. Ethernet frames have source and destination MAC addresses corresponding to their source and destination Ethernet switches. When an Ethernet frame sent out by a source switch is received by an intermediate or destination Ethernet switch, the receiving-switch observes the port on which the frame was received and the source address of the frame. It then builds up a forwarding table for use in future frame switching. The forwarding table maps destination address to output port and is built up using the source address of a received frame and the input port on which it was received. Over time, the network builds up forwarding state enabling efficient switching of Ethernet frames.
  • [0060]
    It can thus be seen that conventional switched Ethernet networks using auto-learning must be simply-connected—ie there must be one and only one path between each and every node of the network. If there were multiple paths between any two nodes, the input port on which a frame is received from a source node would not be a reliable indicator of the correct output port to forward future traffic destined for that node. Inconsistencies in forwarding tables on Ethernet switches would result in looping of frames. Moreover, if there exists any loop in an part of the network then any broadcast packet will be continuously duplicated in that loop and the duplicates forwarded all over the whole network, limited only by the link capacities concerned. This inevitably results in catastrophic failure of the network.
  • [0061]
    According to the present invention, instead of using auto learning to configure forwarding tables in Ethernet switches, forwarding tables are directly configured using a novel Ethernet control plane. FIG. 3 shows a control plane/transport plane architecture for controlling the Ethernet carrier network of FIG. 1. The ITU-T Automatically Switched Transport Network (ASTN), sometimes known as the Automatically Switched Optical Network (ASON), may be used. The general architectural specification of the ASTN is set out in ITU-T Recommendation G.8080.
  • [0062]
    Control plane 30 comprises a number of connection controllers 32 a, 32 b, 34 a, 34 b, 36 and 38 corresponding to each of Ethernet switches 22 a, 22 b, 24 a, 24 b, 26 and 28 of carrier network 20 (not all connection controllers are labelled in FIG. 3, for clarity). Control Plane 30 may be conceptually thought of as lying ‘above’ transport plane 32 which comprises the Ethernet switches 22 a, 22 b, 24 a, 24 b, 26 and 28 of carrier network 20. Connection controllers (CCs) 34 are logical agents each corresponding to a respective Ethernet switch (which represent cross connects in ASTN terminology) in transport plane 32. Each CC controls the switching of its respective switch using Connection Control Interface (CCI) signalling (shown as dofted lines in FIG. 3). CCI signalling is used to directly configure the forwarding tables used by Ethernet switches 22 a, 22 b, 24 a, 24 b, 26 and 28 of carrier network 20. CCs may communicate between themselves using Network to Network Interface (NNI). Typically, CCs will exchange information regarding their operational state and the state, in particular the capacity, of their communications links using NNI signalling. Other control plane functions such as heartbeat, ping and circuit monitoring may be provided using the ITU-T standard-in-preparation currently referred to as Y.17ethOAM.
  • [0063]
    While CCs 32 a, 32 b, 34 a, 34 b, 36 and 38 are logically separate from Ethernet switches 22 a, 22 b, 24 a, 24 b, 26 and 28, the reader will understand that they may be implemented in the same physical nodes. Furthermore, NNI signalling may take place over the same communications links used for transporting user traffic.
  • [0064]
    FIG. 5 shows how control plane 30 interacts with transport plane 32 to establish a point-to-point connection across carrier network 20. Typically, the connection will be bi-directional, although this can simply be considered as the combination of two unidirectional point to point connections. A request to establish a connection specifying a required bandwidth and an explicit route across carrier network 20 is generated for example by a supervisory network management node (not shown) or distributed network management or function. The explicit route will have been determined in accordance with a conventional routing protocol taking into account the topology of the carrier network, the operational state of network resources and the bandwidth requirements of existing and possible future connections. The route to be taken by the exemplary connection shown in FIG. 5 spans Ethernet switches 22 a, 24 a, 24 b and 22 b over communications links 48.
  • [0065]
    The request to establish a connection is first sent to CC 32 a. On receipt, of the request, CC 32 a checks whether the communications link between switches 22 a and 24 a has sufficient capacity to support the required bandwidth. If so, it forwards a connection setup request message 50 to CC 34 a specifying the required bandwidth and explicit route. CC 34 a then checks whether the communications link between switches 24 a and 24 b has sufficient capacity to support the required bandwidth. The process continues until the connection setup message request 50 reaches CC 32 b. Along the route, CCs may optionally reserve bandwidth of their respective switches and communication links so as to avoid race conditions where competing connections are setup over the same resources.
  • [0066]
    When connection setup request message 50 reaches CC 32 b, if there is sufficient bandwidth along the entire path to support the required connection, then CC 32 b sends a connection setup response message 52 back to CC 34 b, CC 34 a and finally to CC 32 a. As the connection setup response message 52 traverses the CCs, each CC sends CCI signalling 54 to its respective switch to configure the forwarding tables of each switch, thereby to establish the forwarding state required to setup the connection.
  • [0067]
    It will be appreciated that the mechanism for establishing connections across carrier network 20 described above is merely exemplary and other well-known mechanisms may be used.
  • [0068]
    How forwarding tables of the Ethernet switches of carrier network 20 are used to support connections is a key aspect of the present invention and will now be described in detail.
  • [0069]
    Typically, there will be many thousands or tens of thousands of connections established across a carrier network at any time. These connections will share the physical resources of the carrier network—ie the switches and communications links. Thus, each switch will typically have a large number of connections established through it at any point in time. However, each switch must be able to forward data traffic according to the explicit route requirements of the specific connection through which that traffic is being sent. A likely scenario is that the carrier network will need to establish multiple connections from the same source nodes, multiple connections to the same destination nodes and multiple connections both from the same source nodes and to the same destination nodes. However, for traffic engineering, even the latter connections may need to be established through different routes across the network. Furthermore, these routes may need to converge and diverge again within the carrier network. To support such route flexibility in connections, what is required is that each switch be able to differentiate between data traffic travelling in different connections and forward accordingly.
  • [0070]
    However, conventional switched Ethernet is incapable of this. As described above, conventional Ethernet switches forward traffic based solely on a forwarding table (established through auto learning) mapping destination address to output port. As a result, a conventional Ethernet switch will not be able to differentiate between data traffic having the same destination address, although it may be associated with multiple different connections.
  • [0071]
    According to the present invention, VLAN tags are used in a novel manner to enable differentiation of connections established across a carrier network and thereby to enable differential forwarding. Ethernet switches of carrier network 20 are VLAN-aware and use the combination of destination address and VLAN tag to forward data traffic. This may be achieved by each Ethernet switch storing separate forwarding tables for each VLAN tag configured, the VLAN tag acting as an mapping (or indexing) to the forwarding tables and each forwarding table mapping destination address to output port as normal. Thus the group of forwarding tables provide a mapping from a combination of destination address and VLAN tag to output port.
  • [0072]
    Thus, as shown in FIG. 6, on receiving an Ethernet frame (step 60), the switch first selects a forwarding table based on the VLAN tag contained in the frame (step 62). Then, the switch selects an output port based on the destination address contained in the frame (step 64). Finally, the switch forwards the frame on the selected output port (step 66).
  • [0073]
    Note that this functionality is similar to that performed by the prior art VLAN-aware bridges described above with reference to FIG. 1. However, the use of VLAN tags to enable the establishment and differentiation of connections across a carrier network is believed to be entirely novel and inventive.
  • [0074]
    According to the present invention, VLAN tags and entries in forwarding tables corresponding to connections to be established across the carrier network are directly configured into the appropriate Ethernet switches using the connection setup process described above. Data traffic is associated with a particular connection on entry into the carrier network (more specifically at the ingress PE-Core) by giving the frames a selected VLAN tag as well as destination address (ie the MAC address of the egress PE-Core). Note that encapsulation will already have taken place and thus the raw Ethernet frames received from the customer will not be altered in this process.
  • [0075]
    FIGS. 7 and 8 show how the use of a combination of VLAN tag and destination address enables differentiation between connections. FIG. 9 shows how lack of differentiation in the combination of VLAN tag and destination address necessitates convergence between connections. Each of FIGS. 7 to 9 show connections across a carrier network comprising 4 provider edge Ethernet switches 71, 72, 73 and 74 (corresponding to PE1, PE2, PE3, PE4), further Ethernet switches in core 78 including core Ethernet switch 75, and communications links between the core and edge switches (reference numerals omitted for clarity).
  • [0076]
    In FIG. 7, connections 76 and 77 have both the same source address (edge Ethernet switch 71—PE1) and destination address (edge Ethernet switch 73—PE3). However, the routes that connections 76 and 77 traverse are different.
  • [0077]
    In particular, it can be seen that at core Ethernet switch 75, connections 76 and 77 converge and then immediately diverge. Despite the common destination address, core Ethernet switch 75 is able to differentiate frames belonging to connection 76 from frames belonging to connection 77 (and to forward them accordingly) on the basis of their different VLAN tags. Thus, data traffic in connection 76 has the VLAN tag 2, for example, whereas data traffic in connection 77 has the VLAN tag 1.
  • [0078]
    In FIG. 8, connections 80 and 82 have both the same source address (edge Ethernet switch 71—PE1) and are given the same VLAN tag (in this case the VLAN tag is 1), but have different destination addresses (connection 80 has edge Ethernet switch 73—PE3 while connection 82 has edge Ethernet switch 74—PE4). Again, the routes that connections 80 and 82 traverse are different. In particular, it can be seen that at core Ethernet switch 75, connections 80 and 82 converge and then follow the same path before diverging towards their destination points. Despite the common VLAN tags, core Ethernet switch 75 is able to differentiate frames belonging to connection 76 from frames belonging to connection 77 (and to forward them accordingly) on the basis of their different destination addresses.
  • [0079]
    From FIGS. 8 and 9 it can be seen that, differentiation between Ethernet frames belonging to different connections is achieved according to the combination of destination address and VLAN tag. A difference in either may be used to achieve differential forwarding required for connections.
  • [0080]
    FIG. 9 shows how lack of differentiation in the combination of VLAN tag and destination address necessitates convergence between connections. In FIG. 9, connections 90 and 92 have the same destination address (edge Ethernet switch 73—PE3), and are given the same VLAN tag (in this case the VLAN tag is 1), but have different source address (connection 90 has edge Ethernet switch 71—PE1 while connection 92 has edge Ethernet switch 72—PE2). Again, the routes that connections 90 and 92 traverse are different, but this is only because the data traffic is injected into the carrier network from different ingress points—ie edge Ethernet switches 71 and 72. Once the routes converge at core Ethernet switch 75, they stay converged until their destination at edge Ethernet switch 73. This is because they have the same destination address and VLAN tag and there is no way of differentiating them on the basis of the combination of destination address and VLAN tag. However, it should be noted that one (or both) of the data traffic flows may be re-routed by simply provisioning a new connection with a different VLAN tag and then using that VLAN tag in the MAC header of the Ethernet frames at the ingress point. This re-routing of data flows is hitless since the new connection may be established contemporaneously with the old connection and new Ethernet frames directed into the new connection while earlier frames are still in transit over the old connection. Thus, re-routing may occur without requiring any re-ordering of frames at the destination.
  • [0081]
    So far, only the establishment of point-to-point (ie unicast) connections have been described. However, according to the present invention, point-to-multipoint or multipoint-to-multipoint connections may also be established across Ethernet networks as will now be briefly described. Conventional Ethernet switches are capable of multicast service. Typically this is achieved by configuring the forwarding table with more than one output port (but not necessarily all output ports) for a given multicast destination address. According to the present invention, for relatively small scale multicast operation, a point-to-multipoint connection may be configured as described above but using a combination of VLAN tag and multicast address mapping to more than one output port (but not necessarily all output ports) of selected Ethernet switches. However, this approach is only suitable for relatively small scale multicast operation.
  • [0082]
    According to the present invention, where a carrier network wishes to support a large number of point-to-multipoint or multipoint-to-multipoint connections, Resilient Packet Ring (RPR) are emulated over the Ethernet MAC addressed network using multiple unicast connections established as described above. The following description is given in the context of a virtual private network (VPN) service, i.e. where there is a limited community of interest for each data frame. Two modes of operation are envisaged: a sparse mode for many customers with few sites, and a dense mode for few customers with many sites. The detailed mechanisms are described in one of the Applicants' co-pending U.S. patent application Ser. No. 10/698,833 (Nortel Networks Reference 15877RO) entitled Virtual Private Networks Within A Packet Network Having A Mesh Topology which document is incorporated herein by reference. The dense and sparse modes of operation will now be briefly described with reference to FIGS. 10 and 11.
  • [0083]
    FIG. 10 shows a sparse mode of broadcast operation for many customers with few sites. FIG. 10 shows a part of carrier network 20 comprising a part of fully-meshed core network 100, PE-Core edge Ethernet switches 104 a to d and PE-Edge edge Ethernet switches 102. Broadcast traffic 106 a is received at PE-Core switch 104 b from a customer site. Note that this traffic is broadcast within the context of a particular customer VPN, but is multicast within the context of the carrier network as a whole. The traffic is encapsulated and placed onto an RPR emulated by 4 unidirectional connections 108 a to d. The four connections are established as point-to-point connections as described above. The traffic is forwarded across each connection in turn until it reaches the start point again at PE-Core switch 104 b. On receipt of an encapsulated frame, each endpoint of the four connections determines whether to process the frame for distribution to the customer via PE-Edge edge Ethernet switches 102 to which it is connected. This is done on the basis of broadcast destination addresses contained in the frames, and the VPN membership of customer sites attached to these Ethernet switches. Processing the frames involves decapsulating them and replicating them as required to one or more of PE-Edge edge Ethernet switches 102. It can be seen that no bandwidth need be dedicated to broadcast traffic in the sparse mode of operation since the four point-to-point connections may be trunked—ie they may be used to carry non-broadcast data and other customer's data, whether broadcast or not.
  • [0084]
    FIG. 11 shows a dense mode of broadcast operation for few customers with many sites. FIG. 11 shows a part of carrier network 20 comprising a part of fully-meshed core network 100, PE-Core edge Ethernet switches 104 a to d and PE-Edge edge Ethernet switches 102 as with FIG. 10. Broadcast traffic 110 a is received at PE-Core switch 104 b from a customer site. Note, as above, that this traffic is broadcast within the context of a particular customer VPN, but is multicast within the context of the carrier network as a whole. The traffic is encapsulated and forwarded over a uni-directional connection 110 b to a core switch 116 a. Uni-directional connection 110 b may be trunked. At core switch 116 a, the traffic is forwarded in over a bi-directional RPR 112 emulated by connections between core switches 116 a to d using a bidirectional connection between each pair of adjacent nodes. The RPR is dedicated to a particular customer's broadcast traffic and is not trunked. This is achieved by using a unique VLAN tag for forwarding in the RPR.
  • [0085]
    The traffic is forwarded around RPR 112 to each of the core switches 116 a to d in one direction or the other, whichever is shortest for each respective core switch. Each core switch broadcasts the received frames over uni-directional connections 114 a so that each of PE-Core switches 104 a to d receives the traffic. Then, as with the sparse mode of broadcast operation described above, each PE-Core switch determines whether to process the frame for distribution to the customer via PE-Edge edge Ethernet switches 102 to which it is connected. This is done on the basis of broadcast destination addresses contained in the frames and involves decapsulating and replicating them as required to one or more of PE-Edge switches 102 for onward transmission to the customer sites.
  • [0086]
    It has been described above how connections may be established over a meshed Ethernet carrier network through configuring forwarding tables in network nodes and how data may be forwarded over those connections. The reader will appreciate that connections may be removed by deleting the configuration data from every node over which the connection was established. It is important that all such configuration data is removed to avoid network failure or inefficiency. As described above, the default behaviour of Ethernet switches on receiving a frame addressed to an unknown destination (ie where there is no forwarding state configured for that destination address) is to broadcast the frame out on all output ports. In simply—connected networks this behaviour is appropriate. However, with a meshed topology, this behaviour can be catastrophic. Through partial removal of connections (in particular where configuration data is left at ingress points of a connection but deleted at points further along the connections towards or including the egress point), it remains possible that Ethernet frames for the PE may enter the network but arrive at a point where there is no configuration data for forwarding them, resulting in undesirable broadcast behaviour. Furthermore, partial removal of connections may leave forwarding loops configured by accident.
  • [0087]
    One solution to the problem of partial removal of connections is to alter the behaviour of the Ethernet switches forming the carrier network so that instead of broadcasting unknown traffic, they discard packets and possibly issue an alarm, log or count the discarded packets. However, altering the basic behaviour of Ethernet switches may require a hardware modification. While possible, this is not preferable. However, conventional Ethernet switches generally provide a software configurable function called rate limitation. Preferably, at all or most switches of the carrier rate limitation is used to set a rate of zero, or a low rate if zero is not possible, for broadcast traffic including broadcast-on-unknown traffic.
  • [0088]
    Where this is not possible, other pre-emptive approaches to minimising the problems of partial removal of connections may be used. One approach is to use block lists. Conventional Ethernet switches provide a block list (typically of limited length) which may be used to specify certain destination MAC addresses such that received Ethernet frames addressed to these blocked address will be discarded without forwarding. By blocking, at all or most nodes of the network, the MAC addresses of many (but not all) MAC addresses of provider edge nodes it is possible to minimise the potential dangers of partial removal of connections without over restricting the carrier's flexibility in establishing connections across the network. Notably, it is necessary to block different MAC address at different nodes of the network. Typically, at a given node, the block list will include only the MAC address for provider edge nodes to which no connections are likely to be established through that node. This approach is not easily scaleable with large networks (the limited number of entries in block lists may be exhausted by large numbers of provider edge nodes). However, note that to prevent loops it is only necessary to block rogue frames at one node in any loop. Thus, it is possible to “spread” the blocked destination addresses more thinly across the network and still provide a degree of protection from loops thereby making more efficient use of the limited capacity of block lists.
  • [0089]
    While it is the use of VLAN tags in the present invention that enables flexibility in establishing connections across the network, the failure to remove VLAN state fully leaves the potential for looping of traffic. In particular, the problem will arise where a logical loop is left configured for any single given VLAN tag—ie the output ports of nodes defining a physical loop are left configured with membership of any single VLAN. Thus, another pre-emptive approach to minimising the problems of partial removal of connections is to allocate connections to or from neighbouring or nearby provider edge nodes using mutually exclusive VLAN tag pools. Thus, for example all connections to or from provider edge node PE1 will be guaranteed to have a different VLAN tag to those to or from neighbouring provider edge node PE2. In this way, VLAN loops including both PE1 and PE2 cannot accidentally be formed through the partial removal of connections since by definition any state left configured in PE1 and PE2 will use different VLAN tags. This approach may be generalised by allocating connections to or from n adjacent provider edge nodes using n mutually exclusive VLAN tag pools. n is chosen to be sufficiently large to segregate use of VLAN tag pools as much as possible while providing sufficient flexibility in connection establishment to or from any particular provider edge node (remembering that there are only 4094 possible VLAN tags). With smaller carrier networks it may be possible for each provider edge node to use a different VLAN tag pool. However, with larger carrier networks it will be necessary to re-use VLAN tag pools at topologically distant provider edge nodes otherwise flexibility in connection establishment will be compromised though VLAN tag pools being too small.
  • [0090]
    It will be appreciated that combinations of the above approaches to minimising the problems of partial removal of connections may be employed.
  • [0091]
    While embodiments have been described above with reference to the use of VLAN tags for enabling flexibility in establishing and differential forwarding of data traffic associated with different connections, the reader will appreciate that other tags or identifiers may be used.
  • [0092]
    Also, while embodiments have been described above with reference Ethernet networks and Ethernet frames, to the reader will appreciate that the present invention applies in general to any frame-based, packet-based or cell-based switching network whether at OSI layer 2 or layer 3 network. And to data structures including frames, packets and cells. In the following claims, the term frame-based network, or cognate terms, shall denote any such switching network and the term frame, or cognate terms, shall denote any such data structure.
  • [0093]
    The reader will appreciate that the methods described above may be implemented in the form of hardware or software operating on conventional data processing hardware.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5485455 *Jan 28, 1994Jan 16, 1996Cabletron Systems, Inc.Network having secure fast packet switching and guaranteed quality of service
US5560038 *Nov 28, 1995Sep 24, 1996Network Peripherals, Inc.Apparatus for translating frames of data transferred between heterogeneous local area networks
US5959990 *Mar 12, 1996Sep 28, 1999Bay Networks, Inc.VLAN frame format
US6151324 *Jun 3, 1996Nov 21, 2000Cabletron Systems, Inc.Aggregation of mac data flows through pre-established path between ingress and egress switch to reduce number of number connections
US6181699 *Jul 1, 1998Jan 30, 2001National Semiconductor CorporationApparatus and method of assigning VLAN tags
US6249521 *Dec 18, 1997Jun 19, 2001Advanced Micro Devices, Inc.Method and apparatus for creating a port vector
US6449279 *Nov 20, 2000Sep 10, 2002Enterasys Networks, Inc.Aggregation of data flows over a pre-established path to reduce connections
US6515993 *May 28, 1999Feb 4, 2003Advanced Micro Devices, Inc.Method and apparatus for manipulating VLAN tags
US6563832 *Mar 10, 1999May 13, 2003Cisco Technology, Inc.Token ring bridge distributed in a switched fabric
US6788681 *Feb 25, 2000Sep 7, 2004Nortel Networks LimitedVirtual private networks and methods for their operation
US6789121 *Jun 28, 2002Sep 7, 2004Nortel Networks LimitedMethod of providing a virtual private network service through a shared network, and provider edge device for such network
US6990106 *Mar 19, 2001Jan 24, 2006AlcatelClassification and tagging rules for switching nodes
US7046680 *Nov 28, 2000May 16, 2006Mci, Inc.Network access system including a programmable access device having distributed service control
US7079544 *Feb 12, 2001Jul 18, 2006Hitachi, Ltd.Apparatus and method for interworking between MPLS network and non-MPLS network
US7492768 *May 30, 2003Feb 17, 2009Electronics And Telecommunications Research InstituteSystem and method for VLAN configuration of E-PON, and recording medium with stored program thereof
US7548541 *May 16, 2003Jun 16, 2009Alcatel-Lucent Usa Inc.Managing VLAN traffic in a multiport network node using customer-specific identifiers
US7558273 *Jul 7, 2009Extreme Networks, Inc.Methods and systems for associating and translating virtual local area network (VLAN) tags
US20020191250 *Jun 29, 2001Dec 19, 2002Graves Alan F.Communications network for a metropolitan area
US20030037163 *Mar 8, 2002Feb 20, 2003Atsushi KitadaMethod and system for enabling layer 2 transmission of IP data frame between user terminal and service provider
US20030067928 *Sep 24, 2002Apr 10, 2003Gonda Rumi SheryarMethod for supporting ethernet MAC circuits
US20030142674 *Oct 8, 2002Jul 31, 2003Nortel Networks LimitedLabel control method and apparatus for virtual private LAN segment networks
US20030152075 *Jun 24, 2002Aug 14, 2003Hawthorne Austin J.Virtual local area network identifier translation in a packet-based network
US20030214962 *May 15, 2002Nov 20, 2003Mark Allaye-ChanMethod and apparatus for bandwidth optimization in network ring topology
US20030237002 *Dec 11, 2002Dec 25, 2003Hitachi, Ltd.Network node and communication system
US20040223501 *Dec 27, 2001Nov 11, 2004Mackiewich Blair T.Method and apparatus for routing data frames
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7359383 *Mar 29, 2004Apr 15, 2008Hewlett-Packard Development Company, L.P.Load balancing with mesh tagging
US7697528 *Nov 1, 2005Apr 13, 2010Nortel Networks LimitedMultilink trunking for encapsulated traffic
US7729274Jul 28, 2006Jun 1, 2010Ciena CorporationSmart ethernet mesh edge device
US7808997Feb 6, 2009Oct 5, 2010Huawei Technologies Co., Ltd.Method and system for forwarding data between a plurality of provider Ethernet networks
US7817603 *Apr 23, 2004Oct 19, 2010Utstarcom Telecom Co., Ltd.Method and apparatus for multi-antenna signal transmission in RF long-distance wireless BS
US7822075 *Apr 9, 2004Oct 26, 2010Utstarcom Telecom Co., Ltd.Method and system of signal transmission in base transceiver station based on remote radio head
US7969888 *Jun 28, 2011Futurewei Technologies, Inc.Data communications network for the management of an ethernet transport network
US8005081 *Aug 23, 2011Nortel Networks LimitedEvolution of ethernet networks
US8064467Nov 30, 2006Nov 22, 2011Level 3 Communications, LlcSystems and methods for network routing in a multiple backbone network architecture
US8085676Dec 13, 2007Dec 27, 2011Nortel Networks LimitedMethod and system for looping back traffic in QIQ ethernet rings and 1:1 protected PBT trunks
US8116331Jul 1, 2009Feb 14, 2012Nec CorporationCommunication system, network apparatus, communication recovery method for use therein, and program thereof
US8140654Mar 28, 2008Mar 20, 2012Futurewei Technologies, Inc.Verifying management virtual local area network identifier provisioning consistency
US8149836 *Sep 10, 2007Apr 3, 2012Tejas Israel LtdMethod and system for relaying frames through an ethernet network and bridge therefor
US8259713Feb 6, 2009Sep 4, 2012Level 3 Communications, LlcSystems and methods for network routing in a multiple backbone network architecture
US8274989Mar 30, 2007Sep 25, 2012Rockstar Bidco, LPPoint-to-multipoint (P2MP) resilience for GMPLS control of ethernet
US8320236 *Dec 18, 2007Nov 27, 2012Zte CorporationMethod for processing ethernet ring message and an ethernet ring protection system using the method
US8340106Dec 25, 2012Microsoft CorporationConnecting multi-hop mesh networks using MAC bridge
US8369330 *Jun 30, 2006Feb 5, 2013Rockstar Consortium LPProvider backbone bridging—provider backbone transport internetworking
US8422513 *Apr 16, 2013Nokia Siemens Networks OyProviding station context and mobility in a wireless local area network having a split MAC architecture
US8498297Aug 26, 2005Jul 30, 2013Rockstar Consortium Us LpForwarding table minimisation in ethernet switches
US8514878Aug 24, 2012Aug 20, 2013Rockstar Consortium Us LpPoint-to-multipoint (P2MP) resilience for GMPLS control of ethernet
US8526446Feb 3, 2006Sep 3, 2013Level 3 Communications, LlcEthernet-based systems and methods for improved network routing
US8553697Dec 14, 2012Oct 8, 2013Rockstar Consortium Us LpProvider backbone bridging—provider backbone transport internetworking
US8578048Jul 30, 2009Nov 5, 2013Nectar Holdings, Inc.System and method for routing commands in a modularized software system
US8582575 *Sep 1, 2010Nov 12, 2013Electronics And Telecommunications Research InstituteBackbone edge switching apparatus and packet processing method of the backbone edge switching apparatus
US8675519Aug 10, 2011Mar 18, 2014Rockstar Consortium Us LpEvolution of ethernet networks
US8693339 *Dec 10, 2009Apr 8, 2014Verizon Patent And Licensing Inc.LDP extension for forwarding path congestion notification
US8755390 *Sep 21, 2012Jun 17, 2014International Business Machines CorporationNetwork data congestion management method
US8767742 *Apr 22, 2010Jul 1, 2014International Business Machines CorporationNetwork data congestion management system
US8767749 *Jun 12, 2009Jul 1, 2014Tejas Israel LtdMethod and system for transparent LAN services in a packet network
US8787394Feb 1, 2011Jul 22, 2014Ciena CorporationSeparate ethernet forwarding and control plane systems and methods with interior gateway route reflector for a link state routing system
US8854955Dec 14, 2012Oct 7, 2014Ciena CorporationMesh restoration and bandwidth allocation systems and methods for shared risk connection groups
US8862768 *Oct 19, 2009Oct 14, 2014Broadcom CorporationMethod and system for packetizing data for servicing traffic end-to-end
US8885634Nov 30, 2007Nov 11, 2014Ciena CorporationSystems and methods for carrier ethernet using referential tables for forwarding decisions
US8923292Apr 6, 2005Dec 30, 2014Rockstar Consortium Us LpDifferential forwarding in address-based carrier networks
US8929365Feb 23, 2009Jan 6, 2015Telcordia Technologies, Inc.Efficient, fault-tolerant multicast networks via network coding
US8948055Nov 2, 2012Feb 3, 2015Ciena CorporationResilient interworking of shortest path bridging and Ethernet virtual private networks
US8976793Nov 21, 2012Mar 10, 2015Rockstar Consortium Us LpDifferential forwarding in address-based carrier networks
US8995451Aug 31, 2012Mar 31, 2015Level 3 Communications, LlcSystems and methods for network routing in a multiple backbone network architecture
US9020888Mar 15, 2013Apr 28, 2015Nectar Services Corp.Data replicating systems and data replication methods
US9036641Sep 9, 2013May 19, 2015Rpx Clearinghouse LlcProvider backbone bridging—provider backbone transport internetworking
US9077563Nov 25, 2009Jul 7, 2015Fujitsu LimitedSwitch for identifying extended group information of ports
US9094337May 23, 2013Jul 28, 2015Cieno CorporationSource identification preservation in multiprotocol label switching networks
US9100333Oct 1, 2013Aug 4, 2015Nectar Holdings, Inc.System and method for routing commands in a modularized software system
US9112772 *Jun 28, 2012Aug 18, 2015Nippon Telegraph And Telephone CorporationOLT and frame transfer control method
US9118590Mar 21, 2013Aug 25, 2015Rpx Clearinghouse LlcVLAN support of differentiated services
US9143445May 8, 2013Sep 22, 2015Brocade Communications Systems, Inc.Method and system for link aggregation across multiple switches
US9154416Mar 13, 2013Oct 6, 2015Brocade Communications Systems, Inc.Overlay tunnel in a fabric switch
US9154433 *Aug 17, 2012Oct 6, 2015Nicira, Inc.Physical controller
US9160567May 26, 2011Oct 13, 2015Huawei Technologies Co., Ltd.Method, apparatus, and system for establishing a virtual local area network connection
US9178717 *Apr 7, 2011Nov 3, 2015Adtran, Inc.Systems and methods for enabling leaf isolation in a multi-node tree network
US9203644Apr 9, 2009Dec 1, 2015Ciena CorporationEnabling an Ethernet ring network to scalably support a hub-and-spoke connectivity model
US9270572Dec 6, 2011Feb 23, 2016Brocade Communications Systems Inc.Layer-3 support in TRILL networks
US9276768Mar 5, 2013Mar 1, 2016Nokia Solutions And Networks OyProviding station context and mobility in a wireless local area network having a split MAC architecture
US9288104Oct 25, 2012Mar 15, 2016Nicira, Inc.Chassis controllers for converting universal flows
US9300593Jan 31, 2013Mar 29, 2016Nicira, Inc.Scheduling distribution of logical forwarding plane data
US9306864Jan 31, 2013Apr 5, 2016Nicira, Inc.Scheduling distribution of physical control plane data
US9306910Oct 21, 2013Apr 5, 2016Vmware, Inc.Private allocated networks over shared communications infrastructure
US9319268Apr 14, 2014Apr 19, 2016Rpx Clearinghouse LlcQ-in-Q Ethernet rings
US9319336Jan 31, 2013Apr 19, 2016Nicira, Inc.Scheduling distribution of logical control plane data
US9319337Jan 31, 2013Apr 19, 2016Nicira, Inc.Universal physical control plane
US9319338Jan 31, 2013Apr 19, 2016Nicira, Inc.Tunnel creation
US9338087Jun 22, 2015May 10, 2016Ciena CorporationSource identification preservation in multiprotocol label switching networks
US9344346 *Feb 19, 2011May 17, 2016Deutsche Telekom AgLooping MPLS paths at forwarding level for connectionless MPLS networks
US9350564Dec 19, 2014May 24, 2016Brocade Communications Systems, Inc.Spanning-tree based loop detection for an ethernet fabric switch
US9350680Jan 9, 2014May 24, 2016Brocade Communications Systems, Inc.Protection switching over a virtual link aggregation
US9350696Feb 1, 2013May 24, 2016Nicira, Inc.Handling NAT in logical L3 routing
US9350811Mar 15, 2013May 24, 2016Nectar Services Corp.Load balancing networks and load balancing methods
US9356817 *Apr 30, 2012May 31, 2016Aruba Networks, Inc.System and method for mitigating multicast message duplication in a wireless network
US9356862Sep 5, 2014May 31, 2016Rpx Clearinghouse LlcDifferential forwarding in address-based carrier networks
US9369301 *Aug 8, 2014Jun 14, 2016International Business Machines CorporationOverlay network capable of supporting storage area network (SAN) traffic
US9374301May 8, 2013Jun 21, 2016Brocade Communications Systems, Inc.Network feedback in software-defined networks
US9385954Mar 31, 2014Jul 5, 2016Nicira, Inc.Hashing techniques for use in a network environment
US20060007917 *Nov 8, 2004Jan 12, 2006Masahiro SaitoFrame transfer method and edge switch
US20060215672 *Feb 3, 2006Sep 28, 2006Level 3 Communications, Inc.Ethernet-based systems and methods for improved network routing
US20070047540 *Aug 26, 2005Mar 1, 2007Nigel BraggForwarding table minimisation in Ethernet switches
US20070076719 *Jun 30, 2006Apr 5, 2007Nortel Networks LimitedProvider backbone bridging - provider backbone transport internetworking
US20070086429 *Nov 30, 2006Apr 19, 2007Level 3 Communications, Inc.Systems and Methods for Network Routing in a Multiple Backbone Network Architecture
US20070098006 *Nov 1, 2005May 3, 2007Nortel Networks LimitedMultilink trunking for encapsulated traffic
US20070160012 *Apr 23, 2004Jul 12, 2007Utstarcom Telecom Co., Ltd.Method and apparatus for multi-antenna signal transmission in rf long-distance wireless bs
US20070177597 *Feb 2, 2006Aug 2, 2007Yu JuEthernet connection-based forwarding process
US20070195832 *Apr 9, 2004Aug 23, 2007Utstarcom Telecom Co. Ltd.Method and system of signal transmission in base transceiver station based on remote radio head
US20070211736 *Mar 13, 2006Sep 13, 2007Microsoft CorporationeConnecting multi-hop mesh networks usinc MAC Bridge
US20080062994 *Sep 10, 2007Mar 13, 2008Ethos Networks LtdMethod and system for relaying frames through an ethernet network and bridge therefor
US20080095047 *Dec 13, 2007Apr 24, 2008Nortel Networks LimitedMethod and system for looping back traffic in qiq ethernet rings and 1:1 protected pbt trunks
US20080107027 *Apr 3, 2007May 8, 2008Nortel Networks LimitedEngineered paths in a link state protocol controlled Ethernet network
US20080151863 *Oct 31, 2007Jun 26, 2008Level 3 Communications LlcSystem and method for switching traffic through a network
US20080267072 *Mar 28, 2008Oct 30, 2008Futurewei Technologies, Inc.Data Communications Network for the Management of an Ethernet Transport Network
US20080267080 *Mar 27, 2008Oct 30, 2008Futurewei Technologies, Inc.Fault Verification for an Unpaired Unidirectional Switched-Path
US20080270588 *Mar 28, 2008Oct 30, 2008Futurewei Technologies, Inc.Verifying Management Virtual Local Area Network Identifier Provisioning Consistency
US20080279196 *Apr 6, 2005Nov 13, 2008Robert FriskneyDifferential Forwarding in Address-Based Carrier Networks
US20090141632 *Feb 6, 2009Jun 4, 2009Level 3 Communication, LlcSystems and methods for network routing in a multiple backbone network architecture
US20090141703 *Nov 30, 2007Jun 4, 2009Morteza GhodratSystems and methods for carrier ethernet using referential tables for forwarding decisions
US20090141730 *Feb 6, 2009Jun 4, 2009Huawei Technologies Co., Ltd.Method and system for forwarding data between a plurality of provider ethernet networks
US20090161669 *Dec 21, 2007Jun 25, 2009Nortel Netowrks LimitedEvolution of Ethernet Networks
US20090168780 *May 8, 2008Jul 2, 2009Nortel Networks LimitedMPLS P node replacement using a link state protocol controlled ethernet network
US20090213854 *Feb 23, 2009Aug 27, 2009Telcordia Technologies, Inc.Efficient, fault-tolerant multicast networks via network coding
US20090290537 *Nov 26, 2009Nokia Siemens NetworksProviding station context and mobility in a wireless local area network having a split MAC architecture
US20100002711 *Jan 7, 2010Hajime AokiCommunication system, network apparatus, communication recovery method for use therein, and program thereof
US20100008365 *Jan 14, 2010Porat HayimMethod and system for transparent lan services in a packet network
US20100030883 *Jul 30, 2009Feb 4, 2010Kiefer MatthewMethod for overcoming address conflicts among disparate networks is a network management system
US20100030884 *Jul 30, 2009Feb 4, 2010Kiefer MatthewPublish and subscribe method for real-time event monitoring in a system for managing a plurality of disparate networks
US20100030895 *Jul 30, 2009Feb 4, 2010Kiefer MatthewSystem for remotely managing and supporting a plurality of networks and systems
US20100030915 *Jul 30, 2009Feb 4, 2010Kiefer MatthewSystem and method for routing commands in a modularized software system
US20100135307 *Nov 25, 2009Jun 3, 2010Fujitsu LimitedSwitch
US20100188968 *Dec 18, 2007Jul 29, 2010Zte CorporationMethod for processing ether rig net message and an ether rig net protection system using the method
US20100238813 *Sep 23, 2010Nortel Networks LimitedQ-in-Q Ethernet rings
US20100260196 *Oct 14, 2010Nortel Networks LimitedEnabling an Ethernet Ring Network to Scalably Support a Hub-And-Spoke Connectivity Model
US20110022721 *Oct 19, 2009Jan 27, 2011Wael William DiabMethod and system for packetizing data for servicing traffic end-to-end
US20110141891 *Jun 16, 2011Verizon Patent And Licensing, Inc.Ldp extension for forwarding path congestion notification
US20110142047 *Sep 1, 2010Jun 16, 2011Electronics and Telecommunications Rearch InstituteBackbone edge switching apparatus and packet processing method of the backbone edge switching apparatus
US20110222439 *Sep 15, 2011Huawei Technologies Co., Ltd.Method, apparatus, and system for establishing a virtual local area network connection
US20110261697 *Apr 22, 2010Oct 27, 2011International Business Machines CorporationNetwork data congestion management system
US20120076014 *Mar 29, 2012Ciena CorporationMethod and apparatus for traffic engineering in shortest path bridged networks
US20130021910 *Jan 24, 2013International Business Machines CorporationNetwork data congestion management method
US20130094513 *Apr 18, 2013Fujitsu LimitedRelay apparatus and control method
US20130103818 *Aug 17, 2012Apr 25, 2013Teemu KoponenPhysical controller
US20130176906 *Nov 21, 2012Jul 11, 2013Rockstar Bidco, LPTraffic engineering in frame-based carrier networks
US20130286921 *Apr 30, 2012Oct 31, 2013Gopal AgarwalSystem and method for mitigating multicast message duplication in a wireless network
US20130343204 *Feb 19, 2011Dec 26, 2013Deutsche Telekom AgLooping mpls paths at forwarding level for connectionless mpls networks
US20140112659 *Jun 28, 2012Apr 24, 2014Nippon Telegraph And Telephone CorporationOlt and frame transfer control method
US20140146701 *Jan 31, 2014May 29, 2014Rockstar Consortium Us LpEvolution of ethernet networks
US20140348162 *Aug 8, 2014Nov 27, 2014International Business Machines CorporationOverlay network capable of supporting storage area network (san) traffic
EP2005650A1 *Feb 8, 2007Dec 24, 2008Microsoft CorporationConnecting multi-hop mesh networks using mac bridge
EP2005650A4 *Feb 8, 2007Dec 22, 2010Microsoft CorpConnecting multi-hop mesh networks using mac bridge
EP2051450A1 *Aug 6, 2007Apr 22, 2009Huawei Technologies Co LtdMethod and system for forwarding data between a plurality of provider ethernet networks
EP2066081A1 *Oct 16, 2008Jun 3, 2009Ciena CorporationFlow control using referential tables in a carrier ethernet network
EP2087657A2 *Nov 29, 2007Aug 12, 2009Level 3 Communications, LLCSystem and method for switching traffic through a network
EP2087657A4 *Nov 29, 2007Dec 22, 2010Level 3 Communications LlcSystem and method for switching traffic through a network
EP2141867A1 *Jun 30, 2009Jan 6, 2010Nec CorporationCommunication system, network apparatus, communication recovery method for use therein, and program thereof
EP2153585A2 *Jan 23, 2008Feb 17, 2010Hammerhead Systems, Inc.Mapping pbt and pbb-te traffic to vpls and other services
EP2153585A4 *Jan 23, 2008Nov 27, 2013Brixham Solutions LtdMapping pbt and pbb-te traffic to vpls and other services
EP2227879A1 *Dec 30, 2008Sep 15, 2010Nortel Networks LimitedMpls p node replacement using link state protocol controlled ethernet network
EP2424178A1Oct 2, 2006Feb 29, 2012Nortel Networks LimitedProvider link state bridging
EP2698951A1 *Dec 30, 2008Feb 19, 2014Nortel Networks LimitedMPL P node replacement using a link state protocol controlled ethernet network
EP2750342A2 *Nov 2, 2007Jul 2, 2014Nortel Networks LimitedEngineered paths in a link state protocol controlled ethernet network
EP2800314A2Oct 2, 2006Nov 5, 2014Nortel Networks LimitedProvider link state bridging
WO2007038853A1 *Sep 11, 2006Apr 12, 2007Nortel Networks LimitedProvider backbone bridging - provider backbone transport internetworking
WO2007038856A1Oct 2, 2006Apr 12, 2007Nortel Networks LimitedProvider link state bridging
WO2007087275A3 *Jan 23, 2007Dec 21, 2007Allied Telesis IncMethod and system for improving traffic distribution across a communication network
WO2007113645A2 *Mar 30, 2007Oct 11, 2007Gridpoint Systems Inc.Smart ethernet edge networking system
WO2007113645A3 *Mar 30, 2007Apr 10, 2008Jim ArseneaultSmart ethernet edge networking system
WO2008053252A1Nov 2, 2007May 8, 2008Nortel Networks LimitedTraffic engineered paths in a link state protocol controlled ethernet network
WO2008067493A2 *Nov 29, 2007Jun 5, 2008Level 3 Communications, LlcSystem and method for switching traffic through a network
WO2008067493A3 *Nov 29, 2007Jul 17, 2008Niclas ComstedtSystem and method for switching traffic through a network
WO2008091637A2Jan 23, 2008Jul 31, 2008Hammerhead Systems, Inc.Mapping pbt and pbb-te traffic to vpls and other services
WO2009073976A1Dec 12, 2008Jun 18, 2009Nortel Networks LimitedMethod and system for looping back traffic in qiq ethernet rings and 1:1 protected pbt trunks
WO2009105754A1 *Feb 23, 2009Aug 27, 2009Telcordia Technologies, Inc.Efficient, fault-tolerant multicast networks via network coding
WO2010060373A1 *Nov 24, 2009Jun 3, 2010Huawei Technologies Co., Ltd.Method, apparatus and system for establishing virtual local area network connection
WO2010115260A1 *Mar 8, 2010Oct 14, 2010Nortel Networks LimitedEnabling an ethernet ring network to scalably support a hub-and-spoke connectivity model
WO2011131740A1 *Apr 20, 2011Oct 27, 2011International Business Machines CorporationNetwork data congestion management system
WO2014201040A1 *Jun 10, 2014Dec 18, 2014Brocade Communications Systems, Inc.Scalable and segregated network virtualization
Classifications
U.S. Classification370/389
International ClassificationH04L12/46, H04L12/56
Cooperative ClassificationH04L49/354, H04L49/351, H04L49/254, H04L49/253, H04L49/205, H04L45/66, H04L45/64, H04L45/54, H04L12/4645, H04L45/74, H04L12/4641, H04L47/122
European ClassificationH04L45/54, H04L49/20C, H04L45/66, H04L45/64, H04L12/46V1
Legal Events
DateCodeEventDescription
Apr 6, 2004ASAssignment
Owner name: NORTEL NETWORKS LIMITED, CANADA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ASHWOOD-SMITH, PETER;ALLAN, DAVID;REEL/FRAME:015184/0758
Effective date: 20040405
Owner name: NORTEL NETWORKS LIMITED, CANADA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FRISKNEY, ROBERT;BRAGG, NIGEL;PARRY, SIMON;REEL/FRAME:015184/0706
Effective date: 20040405
Oct 28, 2011ASAssignment
Owner name: ROCKSTAR BIDCO, LP, NEW YORK
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:027143/0717
Effective date: 20110729
Mar 11, 2013ASAssignment
Owner name: ROCKSTAR CONSORTIUM US LP, TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROCKSTAR BIDCO, LP;REEL/FRAME:029960/0201
Effective date: 20120509
Feb 9, 2015ASAssignment
Owner name: RPX CLEARINGHOUSE LLC, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROCKSTAR CONSORTIUM US LP;ROCKSTAR CONSORTIUM LLC;BOCKSTAR TECHNOLOGIES LLC;AND OTHERS;REEL/FRAME:034924/0779
Effective date: 20150128