WO2009013582A1

WO2009013582A1 - System and method for ethernet label distribution

Info

Publication number: WO2009013582A1
Application number: PCT/IB2008/001855
Authority: WO
Inventors: Attila Takacs; Oktavian Papp; András CSÁSZÁR
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2007-07-20
Filing date: 2008-07-16
Publication date: 2009-01-29

Abstract

There is disclosed a method and system for enhancing the efficiency of packet routing in a packet-switched network such as an Ethernet. The method establishes an LSP (label switched path) toward an edge router by distributing advertising messages that include a label formed of the MAC address of the edge router, and VLAN identifier. When the advertising message is received at an Ethernet bridge or similar node, the node selectively downloads and stores the label information in the database, mapped to the interface on which the message was received. In a preferred embodiment, an Ethernet router receiving the label mapping message includes an enhanced ARP cache that is able to store IP (Internet protocol) prefixes, and the method is further characterized by the step of storing an FEC including IP prefixes bound to the label information in the enhanced ARP cache.

Description

SYSTEM AND METHOD FOR ETHERNET LABEL DISTRIBUTION

CROSS REFERENCE TO RELATED APPLICATION AND CLAIM OF PRIORITY This application is related to, and claims the benefit of the filing date of

U.S. Provisional Patent Application Ser. No. 60/950,944, which was filed on 20 July 2007, and which is incorporated herein by reference.

TECHNICAL FIELD The present invention is directed, in general, to the control of packet- switched networks, such as Ethernets, and it is directed more specifically to a manner of establishing forwarding paths in an Ethernet network and populating network-node databases through Ethernet label distribution.

BACKGROUND

Networks allow computing devices to communicate with each other. There are many types of computing devices, such as laptops, workstations, and mainframe computers. While these devices are useful in and of themselves, networking them together allows for the sharing of data and computing resources. Networks also permit communication by the user of one computer with the users of one or more others through such applications as email and instant messaging. Some computing devices, such as VoIP (voice over Internet protocol) telephones, have person to person communications as their primary purpose. While any two computing devices may, of course, be connected together, it would be impractical to connect even a small number of devices directly to each other. The advantage of providing a network that allows the sharing of interconnecting pathways should be readily apparent. For this to be possible, however, certain rules must be developed to govern use of the network and the allocation network resources. In addition, since there are many manufacturers of both computing devices and network equipment, certain standards for network architecture and communication have been promulgated.

An Ethernet is a type of network that has been in use for many years and is still gaining in popularity. Ethernets are packet switched networks. Such networks operate by dividing the information to be communicated into discreet units of data called packets. Each packet contains not only data or control information, but is provided with the address of the intended recipient and other routing information as well. Some type of sequence number is included so that the packet-transmitted information can be reassembled into its original form. An Ethernet standard promulgated by the IEEE (Institute of Electrical and Electronics Engineers) is known as IEEE 802.3, although there are several other related standards also relevant to Ethernet operation. Another organization, the IETF (Internet Engineering Task Force) has developed many network communication protocols; they are typically designated as RFCs (requests for comment). Two such documents that have relevance to the present invention, for example, are RFC3031 (Multiprotocol Label Switching Architecture) and RFC3036 (Label Distribution Protocol).

For an Ethernet network to forward data, connectivity between constituent nodes must be established. The spanning tree protocol (STP), including protocol extensions RSTP (rapid spanning tree protocol) and MSTP (multiple spanning tree protocol), specified in IEEE 802.1Q, may be used to create connectivity between every bridge in the network. RSTP/MSTP is limited, however, to forwarding over trees, which can result in suboptimal forwarding of Ethernet frames. One strategy proposed to overcome this shortcoming is SPB (shortest path bridging), specified in IEEE 802.1aq. In an SPB scheme, multiple trees are created, each of which is dedicated to forwarding traffic of a specific bridge. To establish network topology, SPB may either use MAC learning or an ISIS (intermediate system to intermediate system) routing protocol. In addition, a new protocol referred to as PBB-TE (provider backbone bridging traffic engineering) is proposed in IEEE 802. lay and provides for the use of Ethernet control plane protocols other than RSTP/MSTP. One option to take advantage of this is the reservation of a MSTID (multiple spanning tree identifier). VLANs assigned this MSTID are out of the control of the MSTP. As another alternative, an Ethernet control plane based on GMPLS (general multiprotocol label switching) has been proposed in the IETF as GELS (G MPLS-controlled Ethernet label switching).

As another alternative, LDP (label distribution protocol) can be used in MPLS (multiprotocol label switching) networks (specified in RFC 3031) to establish LSPs (label switched paths). In MPLS, two LSPs (label switching routers) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding may be achieved using LDP. where one LSR informs another of the label bindings it has made. LSRs distribute labels to support MPLS routing along normally-routed paths.

MPLS is a network architecture that assigns groups of incoming packets to FECs (forwarding equivalency classes). The packets are routed along LSPs based on pre-allocated labels mapped to and FEC. The labels are added to packet headers when the packets enter the network according to the general procedure outlined in the LDP specification (RFC3036).

Figure 1 is a simplified block diagram illustrating the management of LDP headers according to a standard MPLS protocol. In this example, exemplary packets enter the network 10 through ingress LER (label edge router) 15. In accordance with a standard MPLS protocol, the MAC address, here referred to as MAC1 , is removed and MPLS shim header L1 is added, indicating the address of the node to which the packet is to be forwarded. Adding the shim header L1 is sometimes referred to as "pushing" the label. A corresponding MAC address header portion MAC2 is also added, and the packet is forwarded from LER 15 to LSR 20 in a first LDP session. When the packet arrives at LSR 20, shim header L1 is removed and replaced with shim header L2, indicating the address of the node to which the packet is next to be forwarded. This MPLS procedure is sometimes referred to as "label swapping". Correspondingly, the MAC address header MAC2 is removed and replaced with MAC address header MAC3. The packet is forwarded from LSR 20 to LSR 25 in a second LDP session. -A-

The number of components depicted in the example of Figure 1 is meant for illustration, and in actual networks there may be any number of LSRs. In Figure 1 , however, LSR 25 is the penultimate LSR in network segment 10 as it immediately precedes egress LER 30. For this reason, when the data packet arrives at LSR 25 the MPLS shim header is removed entirely, an MPLS procedure sometimes referred to as label "pop". Although a shim header is no longer needed, the MAC address header MAC3 is removed and replaces with a MAC address header MAC4, identifying the egress LER 30. The data packet is then forwarded to egress header 30, where the MAC address header MAC5 is added in place of MAC4, and the data packet is transmitted toward its next destination (not shown).

While LDP based solutions offer numerous advantages over other network management options, there remains a need for more efficient strategies that provide for the reliable routing of data traffic and reduce the overhead burden placed on network resources.

SUMMARY

To address the above-discussed deficiencies of the prior art, it is a primary object of the present invention to provide a method and arrangement for efficiently establishing forwarding paths using a new Ethernet label methodology. Generally speaking, the present invention is directed to an LDP (label distribution protocol) solution that may be implemented as an alternative to MSTP (multiple spanning tree protocol) or SPB (shortest path bridging) with ISIS (intermediate system to intermediate system) routing and to GMPLS RSVP-TE (general multiprotocol label switching; resource reservation protocol - traffic engineering).

In one aspect, the present invention is a method for use in an Ethernet or other packet-switched network. The method establishes an LSP (label switched path) toward an edge router, and includes the steps of generating a label mapping message including label information, the label information including the MAC address of the edge router and an identifier VID1 identifying a VLAN that includes the edge router and sending the label mapping message on at least one edge router interface. The method may further include receiving the label mapping message at a first interface of an Ethernet bridge or similar node, determining whether to store the label in the label mapping message in a forwarding database, and upon determining that the label information should be stored, storing the label information in the database, mapped to the first interface. In a preferred embodiment, an Ethernet router receiving the label mapping message includes an enhanced ARP cache that is able to store IP (Internet protocol) prefixes, and the method is further characterized by the step of storing the FEC and label information in the enhanced ARP cache.

In another aspect, the present invention is a system for routing data packets that includes a router having a message generator arranged to generate a label mapping message including label information, the label information including the MAC address of the router and an identifier identifying a VLAN that includes the router, and at least one additional node, the additional node having a database and a routing protocol function arranged for determining whether to store label information extracted from a received label mapping message in the database.

In yet another one aspect, the present invention is a network node for routing data in a packet-switched network, including a message generator arranged to generate a label mapping message including label information, the label information including the MAC address of the router and an identifier identifying a VLAN that includes the router, a network interface arranged for sending the label mapping message on at least one network interface. The node may also include a routing protocol function for determining whether to store label information extracted from a received label mapping message in a database.

The foregoing has outlined rather broadly the features and technical advantages of the present invention so that those skilled in the art may better understand the detailed description of the invention that follows. Additional features and advantages of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art should appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the invention in its broadest form.

Before undertaking the DETAILED DESCRIPTION, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation; the term "or," is inclusive, meaning and/or; the phrases "associated with" and "associated therewith," as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term "controller" means any device, system or part thereof that controls at least one operation, such a device may be implemented in hardware, firmware or software, or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. In particular, a controller may comprise one or more data processors, and associated input/output devices and memory, that execute one or more application programs and/or an operating system program. Definitions for certain words and phrases are provided throughout this patent document, those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior, as well as future uses of such defined words and phrases.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which: Figure 1 is a simplified block diagram illustrating the management of LDP (label distribution protocol) headers in a standard MPLS (multiprotocol label switching) network.

Figure 2 is a simplified block diagram illustrating the management of LDP headers according to an embodiment of the present invention.

Figure 3 is a flow diagram illustrating the basic steps included in a method of establishing an Ethernet LSP (label switched path) according to an embodiment of the present invention.

Figures 4a through 4c are a series of simplified block diagrams illustrating an Ethernet LSP setup sequence according to an embodiment of the present invention.

Figure 5 is a simplified block diagram illustrating a network router according to an embodiment of the present invention.

DETAILED DESCRIPTION

FIGURES 2 through 5, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the present invention may be implemented in any suitably arranged packet-switched network. The present invention is directed to a manner of enhancing the efficiency of packet routing in a packed switched network such as an Ethernet. The present invention is directed to an LDP (label distribution protocol) solution that may be implemented as an alternative, for example, to MSTP (multiple spanning tree protocol) or SPB (shortest path bridging) with ISIS (intermediate system to intermediate system) routing and to GMPLS RSVP-TE (general multiprotocol label switching; resource reservation protocol - traffic engineering).

In the description that follows, it will be understood that networks can be of small or large size, and often change configuration. The schematic network diagrams, therefore, are to be understood as being convenient for illustration of the inventive concept being explained, and not as limiting the networks to which the concept can be applied.

The management of LDP (label distribution protocol) headers in a standard MPLS (multiprotocol label switching) environment is outlined above. The use of label headers according to the present invention will now be described with reference to Figure 2. Figure 2 is a simplified block diagram illustrating the management of LDP headers according to an embodiment of the present invention. In this embodiment, packets enter the network 110, passing through ingress LER 115, then being routed through LSR 120 and LSR 125 before passing out of network 110 through egress LER 130. Note that for clarity, components in Figure 2 are numbered analogously but not identically with the corresponding (but not identical) components of Figure 1. As with Figure 1 , however, the number of components shown has been chosen for convenience in illustration, actual networks and network segments or subnets may contain more or fewer components.

In accordance with the embodiment of Figure 2, an LSP will be established between the ingress edge router 115 and the egress router 130. When a data packet is received at the ingress router 115, however, no MPLS shim header is added, as would be the case with the standard MPLS process described above. Instead, ingress router 115 removes the existing MAC header, here designated MAC1 , and replaces it with a new MAC header MAC2. In accordance with the present invention, the MAC2 header includes the destination MAC address and a VLAN identifier (not separately shown). The data packet is then forwarded to LSR 120. LSR 120 acts as an Ethernet bridge, using native Ethernet switching based on the destination MAC address and VLAN identifier in the MAC2 header, and forwards the data packet toward egress LER 130, in this case via LSR 125. Note that no label swapping is required. (In some applications (not shown), the VLAN identifier may be changed, but this variation is not preferred.) LSR 125 uses native Ethernet switching based on the same destination MAC address and VLAN identifier in the MAC2 header, and forwards the packet to egress LER 130. Egress LER 130 then removes the MAC2 header, determines where the packet must next be transmitted, and adds an appropriate MAC3 header before forwarding the packet toward its next destination (not shown).

An actual packet-switched network, of course, typically has a number of nodes interconnected in various ways. These nodes must frequently make decisions as to which direction received packets should be forwarded. A number of strategies have been developed for facilitating this decision-making. The present invention provides a manner of establishing pre-determined paths for this purpose. Figure 3 is a flow diagram illustrating the basic steps included in a method 300 of establishing an Ethernet LSP (label switched path) according to an embodiment of the present invention.

Turning to the embodiment of Figure 3, at START it is assumed that a number of nodes have been assembled into a packet-switching network, and that each of the nodes is operable according to the present invention. (An accommodation may be made for nodes not so operable, even if the nodes are also configured in the network or subnet in question, so universal operability according to the present invention is not a requirement. Such nodes, however, are ignored for purposes of the present discussion.) The method 300 of Figure 3 begins when a router, and generally an LSR edge router, distributes (step 305) a label mapping message to each neighbor that is within the same Ethernet network or subnet.

The label mapping message, in accordance with the present invention, includes an Ethernet label that includes (and may include only) a MAC address associated with the router and a VLAN ID. This Ethernet label is bound to an FEC by the label mapping message, the FEC containing at least the IP address associated with the interface on which the label mapping message is distributed. If the router has multiple interfaces, a separate FEC may be formed to include each additional IP address associated with each of additional interfaces. In addition, if the router has loopback interfaces configured, it can distribute them and bind them to one or more MAC addresses. The messages distributed from the router are received (step 310) in each of the neighbor nodes, the FEC is examined to determine (step 315) if the interface from which it received the label mapping message is on the shortest path towards the destination identified in the FEC. This determination is made by each node (which is a bridge in the usual case) separately running a routing protocol on their respective control plane IP interfaces. If the node is for some reason unable to run this protocol successfully (not shown), the method could proceed as if a positive determination had been made, though the benefit of performing the determination may in that case be lost. For neighbor nodes of the router originating the message, of course, the determination will be positive. If the determination is negative, that is, the interface is determined not to be on the shortest path, the message may be discarded, and no further action is taken.

In an alternate embodiment (not separately shown), when the routing protocol is run, a determination is made only as to whether the node from which the message was received is closer to the destination than the node bridge running the protocol. In this embodiment, positive and negative determinations are then treated in the same manner as with the shortest-path analysis described above. Finally, in yet another embodiment, the determination is not made at all (also not shown) and a positive determination is simply assumed. This embodiment, however, is not preferred.

In any of the above-described embodiments, when a positive determination (real or assumed) is made, the MAC address and the VLAN ID in the message are downloaded and stored (step 320) in the receiving node's FDB (forwarding database). The outgoing interface corresponding with this entry, of course, is the interface upon which the message was received. In this way, whenever the node has Ethernet frames for forwarding to this MAC address in the given VLAN, the necessary interface is already known and there is no need to run a MAC learning procedure. This will in most applications have the effect of reducing the number of broadcast Ethernet frames in the network, conserving network resources. In addition to storing the MAC address and VLAN ID into the FDB the message receiving node also stores (step 325), in its ARP (address resolution protocol) cache, the binding of the received host address in the FEC with the MAC address and VLAN ID. In some embodiments, the FEC may also include a number of IP address prefixes as well. These may also be stored the ARP cache, although in that case enhanced storage capabilities (that is, data structures) may need to be provided.

Finally, the receiving node forwards (step 330) the message to each of its neighbors except the one from which the message was received. The process continues with each subsequent node receiving a forwarded message, running a routing protocol, and storing and forwarding the message as appropriate. Note that the entire process may be repeated periodically, when requested by one of the network nodes, or when for some other reason it is determined by the edge router to be necessary. Note also that the method 300 described in reference to Figure 3 is only one embodiment, and that certain method steps may be added, or in some cases removed, without departing from the spirit of the invention.

Figures 4a through 4c are a series of simplified block diagrams illustrating an Ethernet LSP setup sequence according to an embodiment of the present invention. Depicted in Figures 4a through 4c is a network 400 having a number of data packet forwarding devices, including at least one edge router. As mentioned above, in application, there could be any number of such elements. An edge router is a router having an operational IP interface with nodes outside of the network segment.

According to this embodiment, network 400, which may for example be an Ethernet LAN, includes an edge router 405, which is in direct communication with bridge 410 and bridge 415. Bridge 415 is in direct communication with bridges 420, 425 and 430, while bridge 410 is in direct communication only with (aside from edge router 405) bridge 420. The other component relationships of network segment 400 should be apparent from Figures 4a though 4c, and need not be described further, except to note that while each of the components depicted is referred by stating their function in network 400 according to the present invention, some or all of them may also have other functions or interfaces. Their function according to the present invention will now be described. In the embodiment of Figure 4, edge router 405 collects a set of the IP addresses of its interfaces (or at least one IP address) in the network segment 400 into an FEC, which will be referred to here as FEC1. Edge router 405 has a MAC address and is associated with a VLAN having a VLAN identifier This MAC address and VLAN identifier will be referred to respectively as MAC1 and VID1 in Figures 4a and 4b. After collecting the IP addresses into FEC1 , the edge router 405 advertises a label, binding FEC1 to a label including MAC1 and VID1. This advertisement is represented in Figures 4a and 4b by arrows labeled "FEC1/MAC1+VID1", going to the two bridges 410 and 415 with which edge router 405 is in direct communication. When the advertising message is received at bridges 410 and 415, they each determine whether the label mapping in the message arrived on the shortest path. If so, each of bridges 410 and 415 populate their respective FDBs with the received information, creating Ethernet connectivity to the MAC1 , VID1 destination. If not, the message may be (but is not necessarily) discarded.

As mentioned above, any of the bridges depicted in Figures 4a through 4c may have additional capabilities or functions. If one of the bridges, for example bridge 410 or 415, is also an edge router (that is, it has an IP interface), then the FEC1 mapping to MAC1 and VID1 is stored in its ARP cache as well.

The bridges forward the label mapping advertising message FEC1/MAC1+VID1 , as illustrated in Figure 4b. As should be apparent this will cause the message to be received in bridges 420, 425, and 440. Upon receipt, they process and forward (not shown) the message advertising FEC1/MAC+VID1 in the same manner as described above in reference to bridges 410 and 415. The procedure continues until the mapping is propagated through out the network segment 400, at which point a multipoint- to-point LSP is established toward the edge router 405 (as indicated by the broken lines of Figure 4c). Figure 5 is a simplified block diagram illustrating selected components of a network router 500 according to an embodiment of the present invention. The router 500 includes a number of network interfaces, here numbered 501a through 501 n. Each of the network interfaces may have its own MAC address and IP address. The network interfaces 501a through 501 n are each connected with a processor (or controller) 505, which controls their operation. In accordance with the present invention, router 500 may act as an edge router, and has a label message generator 510, the label message generator 510 being arranged to generate label mapping messages to advertise the binding of an FEC with a label including a VLAN ID and a MAC address associated with one of interfaces 501a through 501 n. Processor 505 is arranged to send the generated label mapping messages to the network via one of the interfaces. Router 500 is also arranged to receive such messages. Routing protocol function 515 is arranged to determine of a received label mapping message including a label formed of a MAC address and a VLAN was received on an interface representing the shortest path to the destination identified in the label mapping message. (In accordance with an alternate embodiment, routing protocol function 515 may instead or also determine if the node from which the label mapping message was received is closer to the destination than router 500.) An FDB 520 and an ARP cache 525 are provided in router 500 for storing information extracted from a label mapping message as directed by the processor 505 based on the result of determinations made by the routing protocol function 515.

The encoding of the messages involved in populating the FDBs will now be explained in greater detail. Note that while the LDP specification, RFC3036, allows for both 'per interface' and 'per platform¹ label space, Ethernet labels according to the present invention have network-wide significance and therefore 'per platform¹ label space must be used. As described above, the label includes the MAC address of the LSR, and the MAC address cannot be changed. This has several ramifications. Although the standard LDP specification permits either independent or ordered label distribution control, ordered label control must be used to ensure that the label is the same throughout the LSP. As should be apparent, it is also imperative that the same label be used when label mapping for a given FEC to the various LDP peer devices of the LSR. According to an embodiment of the present invention, a TLV (time- length-value encoded object) to populate the FDBs of bridges in the LSP may be defined as:

0 1 2 3

01234567890123456789012345678901

I 0| 0| Ethernet Label | Length |

I Resv I VLAN ID | MAC (highest 2 bytes) |

I MAC Address |

where the fields have the following significance:

Ethernet Label - a value that identifies the TLV as an Ethernet label (this needs to be allocated, there is no currently exiting designation).

Resv - reserved field. In some embodiments, for example, this field may contain one or more flags. VLAN ID and MAC Address fields - these two values together identify the LSP, and in accordance with the present invention are to be used by LSP nodes in making forwarding decisions.

Although the present invention has been described in detail, those skilled in the art should understand that they can make various changes, substitutions and alterations herein without departing from the spirit and scope of the invention in its broadest form.

Claims

CLAIMS:

1. In an Ethernet network having at least one VLAN (virtual local area network), a method for establishing an LSP (label switched path) toward an edge router characterized by the steps of: generating a label mapping message including label information, the label information including the MAC address of the edge router and an identifier identifying a VLAN that includes the edge router; sending the label mapping message on at least one edge router interface.

2. The method as set forth in claim 1 , further characterized by the steps of: receiving the label mapping message at a first interface of at least one Ethernet bridge; determining whether to store the label information in an FDB (forwarding database) of the at least one Ethernet bridge; and upon determining that the label information should be stored, storing the label information, mapped to the first interface, in the FDB of the at least one Ethernet bridge.

3. The method as set forth in claim 2, wherein the determining step includes determining whether the Ethernet node from which the label mapping message was received is on the shortest path towards the destination identified by the label information.

4. The method as set forth in claim 2, wherein the determining step includes determining whether the Ethernet node from which the label mapping message was received is closer to the destination identified by the label information than the receiving at least one Ethernet bridge.

5. The method as set forth in claim 2, wherein the at least one Ethernet bridge is a neighbor node of the edge router.

6. The method as set forth in claim 2, further characterized by the step of forwarding the label mapping message.

7. The method as set forth in claim 2, further characterized by the step of forwarding data packets toward the edge router using label information stored in the forwarding database.

8. The method as set forth in claim 1 , wherein the label mapping message advertises the binding of an FEC (forwarding equivalence class) to the label.

9. The method as set forth in claim 8, further characterized by the steps of: receiving the label mapping message at a an Ethernet router; and storing the binding of the FEC to the label in an ARP (address resolution protocol) cache of the Ethernet router.

10. The method as set forth in claim 8, wherein the advertised FEC includes a plurality of IP (Internet protocol) prefixes.

11. The method as set forth in claim 10, further characterized by the steps of: receiving the label mapping message at an Ethernet router; and storing the prefix address FEC and label information binding in an IP forwarding table.

12. The method of claim 11 , wherein the receiving Ethernet router includes an enhanced ARP cache that is capable of storing IP prefixes, and the method is further characterized by the step of storing the FEC and label information in the enhanced ARP cache.

13. For use in an Ethernet network having at least one VLAN, a router for establishing an LSP characterized by: a message generator arranged to generate a label mapping message including label information, the label information including the MAC address of the router and an identifier Vl D1 identifying a VLAN that includes the router; a network interface arranged for sending the label mapping message on at least one network interface.

14. The router as set forth in claim 13, further characterized by: a routing protocol function for determining whether to store label information extracted from a received label mapping message in an FDB.

15. The router as set forth in claim 14, further characterized by an FDB for storing received label information.

16. The router as set forth in claim 13, further characterized by an ARP cache for storing received label information.

17. A network for the communication of packet data, characterized by: a router having a message generator arranged to generate a label mapping message including label information, the label information including the MAC address of the router and an identifier VID1 identifying a VLAN that includes the router; and at least one additional node having a database and a routing protocol function arranged for determining whether to store label information extracted from a received label mapping message in the database.

18. The network according to claim 19, wherein the network is an Ethernet network.

19. The network according to claim 18, wherein the at least one nodedge.

20. The network according to claim 18, wherein the at least one node ter.