U.S. patent application number 10/818685 was filed with the patent office on 2005-10-06 for traffic engineering in frame-based carrier networks.
Invention is credited to Allan, David I, Ashwood-Smith, Peter, Bragg, Nigel, Friskney, Robert, Parry, Simon.
Application Number | 20050220096 10/818685 |
Document ID | / |
Family ID | 34592719 |
Filed Date | 2005-10-06 |
United States Patent
Application |
20050220096 |
Kind Code |
A1 |
Friskney, Robert ; et
al. |
October 6, 2005 |
Traffic engineering in frame-based carrier networks
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.
Inventors: |
Friskney, Robert; (Harlow,
GB) ; Bragg, Nigel; (Weston Colville, GB) ;
Parry, Simon; (Harlow, GB) ; Ashwood-Smith,
Peter; (Hull, CA) ; Allan, David I; (Ottawa,
CA) |
Correspondence
Address: |
BARNES & THORNBURG
P.O. BOX 2786
CHICAGO
IL
60690-2786
US
|
Family ID: |
34592719 |
Appl. No.: |
10/818685 |
Filed: |
April 6, 2004 |
Current U.S.
Class: |
370/389 |
Current CPC
Class: |
H04L 45/54 20130101;
H04L 49/205 20130101; H04L 45/64 20130101; H04L 49/354 20130101;
H04L 12/4645 20130101; H04L 49/351 20130101; H04L 47/122 20130101;
H04L 49/253 20130101; H04L 45/66 20130101; H04L 49/254 20130101;
H04L 45/74 20130101; H04L 12/4641 20130101 |
Class at
Publication: |
370/389 |
International
Class: |
H04L 012/56 |
Claims
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-vla- n-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:
[0046] 1) an at least partially meshed carrier network;
[0047] 2) the ability to establish explicitly routed connections
across the carrier network between any two edge nodes (traffic
engineering); and
[0048] 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 22a, 22b, 24a, 24b, 26 and 28. Ethernet switches 22a, 22b
and 26 are located at the edges of carrier network 20, whereas
Ethernet switches 24a, 24b, and 28 are located in the core network.
Communications links (shown as straight lines in FIG. 2) are
provided between Ethernet switches 22a, 22b, 24a, 24b, 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 24a, 24b, and 28 are
fully-meshed--ie there is a direct communications link connecting
each core network switch 24a, 24b, and 28 to each other. Edge
network switches 22a, 22b 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 (40a and 40b, 42a and 42b,
and 44a and 44b) are shown connected to carrier network 20 via edge
Ethernet switches 22a and 22b respectively. The communications
links between edge switches 22a and 22b and customer switches 40a,
40b, 42a, 42b, 44a, and 44b may be dedicated links such as T1
leased lines or access links such as digital Subscriber Lines
(DSLs).
[0053] Carrier edge switches 22a, 22b 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 42a may send Ethernet traffic
over communications link 46a to PE-Edge of edge switch 22a. PE-Core
of edge switch 22a encapsulates each Ethernet frame in a further
Ethernet frame using the MAC address of edge switch 22a as the
source address and the MAC address of the appropriate egress
point--in this case edge switch 22b--as the destination address.
The encapsulated traffic is forwarded across a connection
established over communications links 48 of carrier network 20 to
edge switch 22b. 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 22b, the
original frames are stripped out and sent over communications link
46b via PE-Edge of edge switch 22b to customer switch 42b.
[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 32a, 32b, 34a, 34b, 36 and 38 corresponding to each of
Ethernet switches 22a, 22b, 24a, 24b, 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
22a, 22b, 24a, 24b, 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 22a, 22b, 24a, 24b, 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 32a, 32b, 34a, 34b, 36 and 38 are logically
separate from Ethernet switches 22a, 22b, 24a, 24b, 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 22a, 24a, 24b and 22b over communications links
48.
[0065] The request to establish a connection is first sent to CC
32a. On receipt, of the request, CC 32a checks whether the
communications link between switches 22a and 24a has sufficient
capacity to support the required bandwidth. If so, it forwards a
connection setup request message 50 to CC 34a specifying the
required bandwidth and explicit route. CC 34a then checks whether
the communications link between switches 24a and 24b has sufficient
capacity to support the required bandwidth. The process continues
until the connection setup message request 50 reaches CC 32b. 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 32b, if
there is sufficient bandwidth along the entire path to support the
required connection, then CC 32b sends a connection setup response
message 52 back to CC 34b, CC 34a and finally to CC 32a. 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 104a to d and PE-Edge edge Ethernet switches 102.
Broadcast traffic 106a is received at PE-Core switch 104b 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 108a 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 104b. 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 104a to d and PE-Edge edge Ethernet switches 102
as with FIG. 10. Broadcast traffic 110a is received at PE-Core
switch 104b 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 110b to a core switch 116a. Uni-directional connection
110b may be trunked. At core switch 116a, the traffic is forwarded
in over a bi-directional RPR 112 emulated by connections between
core switches 116a 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 116a 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
114a so that each of PE-Core switches 104a 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.
* * * * *