ES2337220A1 - Linkage management procedure in data link level for communications networks, data track linking procedure, networks and network interconnection device that combines both procedures. (Machine-translation by Google Translate, not legally binding) - Google Patents

Abstract

Link management procedure at the data link level for communication networks, data frame routing procedure, network interconnection device and network that combines both procedures. This link management at the data link level (layer 2 of osi) comprises a procedure for building a hierarchical spreading tree from a network bridge {bridge) chosen as a root, from which at least one network bridge hangs connected to said root through a designated port and to which a local hierarchical mac address (hlmac) corresponding to the identifier of the designated port is assigned. The frames with destination address hlmac are routed through a procedure using the hierarchical spanning tree. All bridges (here named as combined bridges) to which the hierarchical local mac address is assigned can also process frames with universal mac addresses assigned to the destination terminals. This hierarchical tree is built together with the standard tree (802.1d), forming a mixed expansion tree comprising both combined bridges and conventional ones operating under 802.1d. (Machine-translation by Google Translate, not legally binding)

Description

Link management procedure at the level of data link for communications networks, procedure of routing of data frames, interconnection device networks and network that combines both procedures.

       \ global \ parskip0.930000 \ baselineskip
    

Technical Field of the Invention

The present invention falls within the framework of Information and communications technologies in general, being applied more particularly for local area networks (LAN) and metropolitan (MAN), such as campus networks Ethernet

Background of the invention

At present, the campus networks implemented for the connection of teaching and research centers are networks High speed trunks (Gigabit Ethernet, ...), integrating different environments and services (voice, data, video) in a single IP infrastructure ("Internet Protocol"), supporting distances of transmission that can go up to identical ranges to those of networks wide area (WAN).

The benefits and economy of Gigabit Ethernet and 10 GE push towards major changes in both LAN networks as MAN, caused by drastic increases in bandwidth and scalability as well as for ease of management and low cost regarding ATM switches and SDH equipment.

To these advances must be added the growing demand for bandwidth by multimedia applications (training  online multimedia, videoconferencing, teleconferences, etc.), the new applications associated with the research and industry (distributed computing, vision artificial, etc.) that demand greater capacity and less delay in communications and the increasing number of equipment connected to campus networks From all this derives the need to have networks Self-configuring, high-performance, scalable Ethernet campus to large network sizes and reduced cost.

Given the predictable proliferation of devices of all kinds on campus networks, the sizes of networks that are contemplate are up to 100,000 devices (network terminals) of which approximately 20,000 can be computers conventional, the rest being devices of various types: sensors, panels, personal assistants (PDA), etc. The number of network bridges (bridges) typical for a network of This type can be around 500.

The routing of frames on bridges network that are currently used is derived from the one defined in the standard IEEE 802.1D. But for the implementation of medium-sized networks or great the use of 802.1D bridges has the following inconveniences:

Switching domains must be fragmented to limit the spread of problems such as thunderstorms frames To do this, it is required to use routers or routers network level ("routers"), or use Multilayer switches to fragment into smaller subnets.

You have to assign and manage IP addresses, and the IP address changes when the user changes from Connection.

A lot of expensive infrastructure is underused due to links blocked by the Tree Protocol Expansion (STP: "Spanning Tree Protocol").

When virtual LAN networks (VLANs) are used, standardized according to IEEE 802.1Q, to separate traffic and broadcast domains within the switched domain, it is possible use the infrastructure efficiently, but it is necessary configure and manage VLANs, as well as design and configure Expansion Trees according to the 802.1Q standard, for later assign the VLANs to them.

There are several proposals to define a scalable and self-configuring Ethernet network architecture, the Most based on additional encapsulates: 802.1ah, UETS / EFR ("Universal Ethernet Telecommunications Service / Ethernet Fabric Routing "), ... These proposals have stacked packages and complexes, which means a scalability of coarse granularity due to the absence of true hierarchy in the proposals, given that the flat addressing of the Access Control is maintained at Medium (MAC) Ethernet.

Here are some of the deficiencies presented by the solutions used for Ethernet networks till the date:

- Layer Three or Multilayer Switches [by example, see Cisco LAN Switching by Kennedy Clark, Kevin Hamilton, CCIE Professional Development series, ISBN: 1-57870-094-9, Cisco Press, 2001]: Although they do not have WAN routing capability as the routers are simpler to configure than these (the Disadvantages of routers are summarized in: complexity by need to manage IP addresses, lower benefits and higher cost for equal benefits due to the higher processing of IP packets with respect to Ethernet frames). However, for the LAN routing still need to define IP segments.

       \ global \ parskip1.000000 \ baselineskip
    

- Switches with routing at source: Although routing at source (or based on source)
can be considered obsolete in fixed networks, it is subject to standardization in ad-hoc networks as is the case of the DSR ["The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks (DSR)" protocol, available at
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-10.txt] . When source routing is used in layer two networks, such as Token Ring, a first drawback is the need, unlike the self-configuration of Ethernet bridges, to assign the identity of all Local Bridges and Networks to maintain transparency, since it must always be the network bridges that perform the routing at source, never the terminal equipment of the network. A second major drawback is the large message overload produced by route discovery; in fact, the bandwidth required grows exponentially with the number of bridges per LAN and the number of ports per bridge. The frame is also extended by extending it with the explicit route, which contains all the addresses of bridges and LANs to cross.

- Switches with centralized routing: They appear as one of the first self-configuring local network background ["Autonet: A High-Speed, Self-Configuring Local Area Network Using Point-to-Point Links" by M. Shoreder et al ., IEEE Journal on Selected Areas in Communications, Vol. 9, No. 8, p. 1318-1335, 1991]. A considerable drawback of "Autonet" is that the compatibility between the Ethernet and Autonet work modes is implemented in the connected computers as terminals, requiring their modification by incorporating a module ("Localnet") located above the software drivers ("drivers") of Ethernet and Autonet. In addition, the links must be point to point, with only one terminal connected in each LAN segment.

- Switches with distributed routing ("Smartbridges", "Rbridges" and LSOM): Unlike "Autonet", "Smartbridges" do not require point-to-point communication ["SmartBridge: A scalable bridge architecture" by TL Rodeheffer et al ., Proceedings of ACM SIGCOMM 2000, 2000], but are not compatible with 802.1D bridges, do not allow to include the speed of the link as a criterion of choice of roads and require global reinitialization in case of reconfiguration by change of topology. The "Rbridges"("RoutingBridges") [see http://www.postel.org/pipermail/RBridge/] are not scalable to very large campus network scenarios, because MAC-based routing produces quite large tables at be flat addresses that do not allow routing routes to be added, so they require excessive memory and slows down the search on bridges for large network sizes. RBridges modify the frame in each hop between RBridges by switching among others, the next jump RBridge field, which complicates frame processing. The routing LSOM ["LSOM: A Link State Protocol Over MAC Addresses for Metropolitan Backbones Using Optical Ethernet Switches" by J. Duato et al ., Proceedings Second IEEE NCA'03, 2003] uses optimal paths, distributes network traffic and It uses the infrastructure well, but neither does it solve the problem of proliferation of MAC addresses.

- Other Switches with routing are those called "Brouters" [definition in
http://en.wikipedia.org/wiki/Brouter]: They are hybrid devices between a network bridge and a router, but they are not compatible with 802.1D bridges and suffer a significant overhead in the process to obtain the delay tables by port

On the other hand, the technology of Trees Multiple Expansion ("MSTP: Multiple Spanning Tree Protocol ") is a field barely explored in practice out of standard (IEEE 802.1s and 802.1Q-2003) and susceptible to optimization. The MSTP is an extension of the Tree Of Rapid Expansion (RSTP) which, in turn, is an evolution of the First specification of the 802.1D standard where the STP is defined: RSTP is defined in the 802.1w standard, which became the edition of the year 2004 (802.1D-2004) of 802.1D.

The routing mechanism that you use Autonet, is called up / down routing ("Up / Down routing ", in English) and is based on assigning a meaning to all network links according to the position of the vertex of the link in the distribution tree: above, if it is closer to the Root Bridge (the tree node that has no father); down, if it's at contrary. To do this, increasing identifiers are assigned to bridges starting from the root bridge and descending level by level to the Leaf Bridges (those without children; a node A is a parent of B if there is a link from A to node B) .The links between nodes to the same height receive orientation according to the identity of the bridge is major or minor. A legal route is the one that never use / cross a link in the upward direction after having used one down, that is, loops are avoided prohibiting the turns up-down. A problem of Routing up / down is that it does not guarantee optimal routes and It becomes less efficient as the network becomes more complex. Another severe drawback is that its performance depends a lot on the root bridge choice.

An evolution of the up / down routing is the Turn-Prohibition (TP) based algorithms [for example, "Application of Network Calculus to General Topologies using Turn-Prohibition" by L. Starobinski et al ., IEEE INFOCOM 2002 p. 1151-1159, 2002]. The Turn Prohibition algorithms normally operate in two phases: in the first one the set of prohibited turns is defined and then the routing tables are constructed. The definition of prohibited turns consists of three phases: construction of the expansion tree, labeling of nodes according to the expansion tree and algorithm for defining the set of prohibited turns. Another subsequent proposal is the tree-based or TBTP ("Tree-Based Turn Prohibition Protocol" in English) [see "Scalable cycle-breaking algorithms for gigabit Ethernet backbones" by FD Pellegrini et al ., Proceedings of IEEE Infocom 2004, 2004 ], which references the prohibited or non-prohibited turns in relation to the expansion tree itself. This protocol is executed centrally, with the inconveniences of unavailability arising in case of reconfiguration of the network due to the fall of links or bridges. The complexity of the TBTP algorithm is O (N 2 d 2) where N is the number of nodes and d the maximum degree of the network graph. The network performance with TBPT (maximum traffic) is lower than with TP.

There is a distributed version of this protocol, dTBTP ("Distributed Tree-Based Turn Prohibition Protocol"), in English [see "Scalable, Distributed cycle-breaking algorithms for gigabit Ethernet backbones" by F. Pellegrini et al ., Journal of Optical Networking Feb. 2006, Vol. 5. No. 2., 2006] that prohibits up to half of the possible turns in the network The performance of dTBTP is much lower than TBTP if the bridge identities are not pre-ordered previously according to distance from root bridge, which is done by assigning a composite identity by joining the cost to the root with the MAC identifier of the bridge to avoid equality of identities in case of cost ties to the root.Convergence is slow requiring a high number of iterations of the prohibition algorithm of turns greater than 15 and increasing with the size of the network up to about 45. To this must be added the routing protocol, based on Bellman-Ford algorithm, for the calculation of routes.

The direct application of the prohibition of turns in routing algorithms such as Djikstra's is not possible in a simple way (eliminating roads that contain prohibited turns from the routing table) because then the roads are not minimal because Djikstra discovers and choose minimum routes in a staggered way when exploring the network from the nodes incorporated successively when discovering the network. Some of the minimum routes discovered will have prohibited turns and others will not. Other methods ["Routing in Turn-Prohibition Based Feed-Forward Networks" by M. Fiddler et al ., NETWORKING 2004, Lecture Notes in Computer Science, LNCS 3042, p.1168-1179, 2004] apply draft prohibition restrictions, but the complexity grows from O (N2) to O (E2), N and E being respectively the number of nodes and links.

Another alternative solution to make Ethernet more scalable is the RSJ hierarchical routing (Hierarchical RSTAA-STAR Protocol) proposed in the Doctoral Thesis of G. Ibáñez ["Contribution to the design of self-configuring Ethernet campus networks", Universidad Carlos III de Madrid, 2005; also available in
http://enjambre.it.uc3m.es/\simgibanez/tesisgif69.pdf]. However, the addresses in RSJ are of variable length, not usable within the standard fields of the Ethernet frame, so an additional encapsulation of the frame is included in which the RSTAA address field ("Rapid Spanning Tree Based" is included) Address Assignment "). RSTAA proposes assignable addresses of variable length implemented as a variable number of successive fields of fixed length, which due to their variable length can only be transported with an additional encapsulation of the frame. The RSJ is an extension of the STAR ("Spanning Tree Alternate Routing Protocol") protocol and does not resolve loops by cross paths in the tree.

A last more recent proposal is the Ethernet Universal Telecommunications Service switch (UETS) described in ES 2246702. The UETS switches also have certain network compatibility restrictions Universal Ethernet Ethernet and IP. Standard bridges (802.1D) do not they can coexist in a compatible way within a UETS domain. The UETS and Ethernet domains are disjoint and the frames at the entrance They are classified and sent to one or another domain. Switches UETS require assignment of layer two OSI addresses hierarchical and masks of configurable length according to the physical topology of the network, being assigned through management, what which is a complex configuration system. To get the local Ethernet addresses of devices in a UETS domain the domain identifier or the IP address must be resolved on a UETS Ethernet DNS server. The mechanism cannot be used ARP [defined in RFC 826 "An Ethernet Address Resolution Protocol ", 1982] to obtain these addresses. UETS switches do not contemplate the use of broadcast and multicast ("broadcast" and "multicast", in English). The only possible reconfiguration of links is for links transversal, which are not part of the hierarchical network, is that is, the entire topology is assumed active, hierarchical and stable. UETS addresses must be stable, because the domain of UETS addressing can be worldwide, therefore, not they can depend on the expansion tree, which when reconfigured I would modify the addresses. UETS is oriented to switches of Banyan type for maximum performance that does not use broadcast, base mechanism of the expansion tree. Although the switches Banyan are very effective for high traffic if it is distributed between ports, network traffic is very centralized by the predominance of client-server traffic and the server positioning at network points well connected. To have high efficiency by switching hardware, the network topology must correspond to that of the hierarchical tree of end port addresses.

In summary, the problem that remains without be solved today and is an end that the present invention is about  give solution, defining functionality Ethernet switches added and its operating protocols that allow to conserve the advantages of known network bridges while eliminating its drawbacks, is to implement high capacity Ethernet networks as self-configuring as possible. They are also objectives of the invention described below maximize the use of the communications infrastructure, through the use of protocols simple and with reduced equipment cost, as well as simplifying the network configuration and maintenance processes.

Description of the invention

The present invention comes to solve the problematic previously exposed, in each and every one of the different aspects commented, conceiving a network protocol of the data link level (second OSI layer) that constitutes a tree hierarchical combined (CHT: "combined hierarchical tree", in English) able to interoperate with conventional network bridges (These are the bridges that use a standard expansion tree: STP or RSTP) and that configures a tree-shaped network topology mixed expansion, where the network bridges that support said CHT protocol form a network without discontinuity and connect in its periphery of conventional bridges such as subtrees.

The network protocol of the data link level that is proposed, here called CHT protocol and so called in Further, it includes two protocols:

- A creation protocol (or establishment / construction) and maintenance (configuration and reconfiguration) of a mixed (or combined) expansion tree that it is formed, according to certain criteria that are defined more forward, both with conventional bridges (operating only according to the Standard: STP or RSTP) as with network bridges operating according to this CHT protocol (and so they are called here combined bridges). In addition, this protocol includes the execution of a process of assigning local MAC addresses hierarchically (here called HLMAC addresses).

- A routing and forwarding protocol hierarchical up-down that performs the processes of dissemination of routes to neighboring network bridges (those that are connected directly by a link) and routing of frames whose destination is the assigned local MAC addresses of hierarchical way, complementing the standard routing (802.1D), through various schemes (vertical routing, transversal and with turning prohibition mechanisms) that are explain later.

The protocol of creation and maintenance of mixed expansion tree (which from here and for short, is designates with the acronym CSTP: "Combined Spanning Tree Protocol") consists of an extension of the tree expansion protocol standard (RSTP or STP), thanks to which it is possible to interoperate with two network levels (one given by flat universal MAC addresses and another determined by hierarchical local MAC addresses), without need additional encapsulation (of the frames with addressing hierarchical within the flat MAC address frames, universal or also global calls).

Said CSTP protocol thus operates on point links. ready, not shared. If the link is not point to point, it is that is, the combined bridge is connected by some port to the minus a conventional bridge or to LAN segments shared by several terminals, said combined bridge operates in said port according to the standard expansion tree protocol (RSTP or STP) and route the frames in the same way as a conventional bridge.

The CSTP state machine is analogous to the of the RSTP but the information exchanged is different. The bridges network operating according to CSTP send, taking as MAC address of source a single MAC address of your port and as the destination MAC a multicast address, and periodically (by default, each 2 seconds) information about this protocol in a special frame (BPDU: "Bridge Protocol Data Unit"). Fields other than BPDU frame that CSTP uses with respect to that of RSTP are:

- the "Protocol Version Identifier" field, constituted by the third octet of the standard BPDU and used in 802.1D to differentiate STP from RSTP, here to distinguish CSTP from they; Y

- a six octet field that is added after the last octet of the standard BPDU and that contains a prefix that is the address assigned to the root port of the recipient network bridge of the BPDU; this field, which here is given the name of RSTCA coordinate ("Rapid Spanning Tree Compact Address"), is used by the originating network bridge that operates according to CSTP to indicate to each neighboring bridge of yours the hierarchical address RSTCA that is assign; the RSTCA coordinate is formed by adding to the prefix (the bridge root port address) port identity corresponding designated, for each designated port of the bridge by the one that connects to each neighbor.

In this context, the root port of a bridge is the one that offers a lower cost path to the root bridge and the designated port is the one that connects the bridge with another or with a network segment The root bridge is the one from which set the lowest cost path for all connected networks the same; and between all the bridges that connect the same segment network, a designated bridge is the one chosen to transmit the frames to the root bridge with the lowest cost (in case of same cost in two bridges of the same segment, the one with the lowest identifier is chosen as the designated bridge).

Network bridges that use this protocol CSTP (combined bridges) exchange with network bridges conventional standard BPDU frames (according to the BPDUs defined for RSTP or STP).

Additionally, the CSTP protocol includes the hierarchical addressing or coordinate assignment function RSTCA Alternatively, the assignment of hierarchical coordinates it can also be done separately from the CSTP protocol when this protocol on each bridge leaves accessible to others programs the necessary information of the roles, states and Port identities for the external CSTP program build equivalent hierarchical addresses with them. In In any case, only hierarchical coordinates are assigned to combined bridges (not conventional bridges).

The combined bridges used for the data exchange 802.1D standard frame format (frame Ethernet) and therefore do not require frame encapsulation, achieving greater compatibility and simplicity than others background solutions (UETS, etc.). The only thing different than the present solution introduced in said standard data frame is the assignment of local MAC addresses hierarchically. TO Unlike the RSTAA addresses of variable length, the RSTCA coordinates are compacted addresses in the standard format MAC addresses of 6 octets, which make it possible to dispense with additional encapsulation of RSJ. And unlike the addresses UETS, do not require explicit identification of the applicable mask on each network switch.

RSTCA coordinates consist of directions Variable length MAC encapsulated in the standard field of MAC address of the standard data frame, which has a fixed length of six octets. A realization option for this variable length address is embedded in the field MAC address standard is to fill with zeros until completing six octets, implicitly indicating the prefix length of the subnet Another option is to use a length mask scheme fixed, which determines the length in octets of the RSTCA coordinate, that is, explicitly indicates the number of subnet levels. For example, using 8 mask bits at all levels of the subnet from the second, allows simplified operation and compatible with bridges up to 254 ports on levels 2 to 6 and up to 62 on the first level. In addition, a mechanism is contemplated additional preventive improper binding to the first level of a bridge with greater number of active ports.

The address assignment mechanism hierarchical that CSTP applies uses the construction mechanisms of the RSTP expansion tree (or STP). The CSTP protocol establishes the expansion tree as standard only among bridges that operate according to the same CSTP (type bridges combined are called here) and relegate subtrees to the bridges of other type (conventional bridges). Once created said tree of expansion, each designated combined bridge (the term bridge designated is used in the same sense as in the 802.1D standard: it is the bridge that routes the traffic of a given LAN so that the designated bridge of a LAN segment is the one designated for all terminals of that LAN) broadcast on your BPDU (in the field of RSCTA coordinate) the HLMAC hierarchical address that you assign to your designated port the connected neighbor bridge (which receives said BPDU). Hierarchical address assignment can also be carried out simultaneously, instead of successively, to the protocol of Standard expansion shaft used (RSTP or STP).

The use of this allocation mechanism directions gives rise to the construction of two trees:

- a hierarchical tree of combined bridges that it is used to route frames destined to MAC hierarchical addresses (HLMAC: "Hierarchical Local MAC");

- the standard expansion tree (built according to the STP or RSTP protocol) created to route the frames intended for global MAC addresses (UMAC: "Universal MAC ").

As a whole, it is thus formed without discontinuity mixed expansion tree, where the bridges operate with each other combined and conventional, the conventional bridges being connected as branches to the hierarchical tree of combined bridges, in shape of subtrees on the periphery of the expansion tree mixed.

HLMAC addresses are assigned automatically using this address assignment mechanism that starts from the root bridge of the tree and reaches the united nodes to terminal equipment (leaf bridges), assigning bits and masks to the bridges of each level (intermediate bridges and leaves) according at the following criteria:

The ports of intermediate bridges and leaf bridges always have HLMAC addresses assigned and, on the other side, the ports of the terminal equipment have UMAC addresses, Factory assigned on your network cards or NIC ("Network Interface Controller "or Network Interface Controller, in Spanish).

This address scheme can be integrated into a general address scheme if the network bridge that also acts as a gateway to other switched networks also has a hierarchical address in your port or connection ports to those networks, which serves as the base prefix of the addresses in the network from which it is root.

How the hierarchical tree matches the standard used for broadcasting frames with UMAC addresses, the expansion tree reconfigurations due to changes in Topology can lead to modifications in some of the assigned hierarchical addresses. In case of reconfiguration of expansion tree, the information is transmitted in the way standard throughout the tree and in all directions using BPDUs from  type known as TCN ("Topology Change Notification") as well as in the fifth octet (field of flags or "flags") of those BPDUs. The assigned HLMAC hierarchical addresses are deleted in all ports or only on the ports affected by the reconfiguration. Until the designated ports are not in role designated, do not send valid hierarchical addresses. For another On the other hand, the routing protocol forwarding processes are immediately interrupt until the stability of the new tree of HLMAC expansion and coordinates. The advantage of using RSTP to HLMAC address assignment and speed of reconfiguration of the tree with RSTP is that obtaining the updated addresses are very fast and the tree is reconfigured very quickly in a time almost equal to of RSTP reconfiguration time.

The global UMAC addresses learned by a port on a combined bridge is deleted in the standard 802.1D form (using "MAC flushing").

In all ports of the combined bridge accept and process frames with UMAC addresses, in order to be Compatible with conventional bridges. The combined bridges participate in the standard expansion tree protocol (STP or RSTP) of said conventional bridges, trying to be the root of the same. If they cannot be, they become connected sheet bridges at the end of the network, never as intermediate nodes. This is achieved because the combined bridges only operate with their port information, not with 802.1D information received by other ports, so they never act as an intermediate node spreading in its BPDUs roads to the root bridge announced by neighboring nodes

Another of the differential advantages of the proposal consists of complete compatibility with the mechanisms 802.1D broadcast and address resolution. The protocol ARP standard is still used for resolution of the IP address to the MAC address, whether global (UMAC) or local (HLMAC). Frames with UMAC addresses are not modified in the combined bridges: all route such frames in a standard way, except the leaf bridges; each leaf bridge connected by link dedicated to a terminal equipment replaces the UMAC of the terminal to which It is connected by the HLMAC assigned to the port where it is connected. The frames with HLMAC addresses are sent unchanged using a hierarchical routing. Each port of a combined bridge Learn a couple of HLMAC-UMAC addresses.

In short, the combined bridges are they behave in the standard 802.1D way of learning source MAC addresses of the frames they receive, with the difference that only addresses are processed in this standard way Global MAC (UMAC), broadcast group ("broadcast") and multicast ("multicast"), while the addresses Hierarchical local MACs (HLMAC) that are used in sending data from a single transmitter to a single receiver ("unicast") are processed by the routing protocol that is then describe.

The routing and forwarding protocol hierarchical up-down (which from here and for In short, it is designated by the acronym HURP: "Hierarchical Up / down Routing Protocol ") exchanges / disseminates information for route "unicast" frames with local destination addresses hierarchical (HLMAC). Such information is transported in frames Special BPDUs for this HURP protocol, whose header contains the protocol version that designates the HURP protocol and the type of message being exchanged, contemplating the following HURP message types:

- Petition Messages: sent by someone recently started router requesting information from neighboring routers.

- Reply messages: messages with the update routing tables and which, in turn, can be of three types:

- Ordinary messages: They are sent every 1-30 seconds, depending on the configuration of the network administrator, to indicate that the link and route follow assets.

- Messages sent in response to messages from petition.

- Messages sent when a cost of a route and that are only sent through the routes on which you have changed, marking the routes that route They have changed recently.

       \ vskip1.000000 \ baselineskip
    

Each entry to the routing table that use the HURP protocol includes:

Known distances to bridges combined from the area, referring by area to the set or domain of the combined bridges (with support of the CSTP protocol) interconnected without discontinuity through the main tree (CST: "Combined Spanning Tree") which constitutes a tree of mixed expansion (of combined bridges and bridges conventional).

Departure port towards bridges destination.

RSTCA address of the combined bridge Next jump to destination.

RSTAA bridge coordinate destination.

With the same periodicity that they exchange BPDUs according to the standard protocol, the combined bridges periodically send, apart from the CSTP BPDUs, BPDUs with the value corresponding to the HURP protocol in the frame type field Ethernet (instead of the value 0x42 h corresponding to the protocol of standard expansion tree) and containing the routes that the bridge broadcast to each of its neighbors. Only the combined bridges Immediate neighbors process them. Conventional bridges (which follow the 802.1D standard by running STP or RSTP) discard this type of HURP BPDU frames. After a while without listening HURP frames, the port of a HURP bridge not connected to any other HURP bridge, stop transmitting them.

The discovery of HURP neighbors complements the knowledge of hierarchical addresses that each combined bridge has to be part of the expansion tree created by the CSTP protocol. This knowledge due to CSTP is it limits its designated bridge (predecessor in the tree) and its bridges Dependents

Reconfiguration in a network with HURP can occur due to a fall of a tree link. In this case it produces reconfiguration of the tree and new port must be chosen designated and root. The corresponding ports are blocked, the which are enabled once the agreement between the two bridges involved: designated bridge port hierarchically superior and root port of the bridge hierarchically bottom connected, within the hierarchical expansion tree. The involved branches erase the UMACs learned. The reconfiguration, which is spread over the network by the indicator bits or "flags" of the CSTP BPDU, similar to RSTP, produce deleting the HLMAC addresses and the tables of routing on all bridges. Erasing both of Addresses such as tables can be total or partial. If erasing of HLMAC addresses and routes is only partial, it is necessary communicate to all bridges the HLMAC address of the bridge that It connected the failed link to the tree. Upon receiving each bridge the Topology change notification, delete routes and addresses HLMAC and blocks the sending of user frames until it is enabled At least the expansion tree. Initially the total deletion of routes and addresses upon receipt of the BPDU with the Topology change. On the other hand, the reconfiguration of the network caused by the fall of a bridge and, in In this case, if the bridge is not a leaf bridge, the expansion tree will crosses, so there is a reconfiguration similar to the described above, but affecting all links in the bridge.

Unlike the known RIP protocol (Routing Information Protocol: it is a protocol of Internal gateway or IGP used by routers to exchange information about IP networks), the HURP protocol operates on hierarchical local addresses (HLMAC), which are layer two of OSI, instead of over network level addresses (IP addresses: layer three).

Another difference with respect to the RIP protocol is that the HURP protocol uses a bridge-type cost metric, such as recommended by IEEE 802.1D. The metric of a destination is calculate as the metric communicated by a neighbor plus the distance in reach that neighbor.

The HURP protocol supports various options of configurable routing algorithm that allows you to adjust the functioning optimally to the network or requirements of the network administrator

A HURP protocol configuration option consists of the complete diffusion of the distance vectors including hierarchically superior and inferior nodes. From this way the costs of the routes to all the nodes via tree of expansion are known and compared to those of the routes that use cross or cross links.

An option to reduce the number of messages is that the HURP protocol announces a route only if the announced metric is less than twice the distance to the bridge Root of the bridge that announces it. The routes can have a time of 10 second life If after this time, they have not been received Messages confirming that this route is active is deleted.

Another option stems from the announcement of HLMAC addresses, prefix type, also allows reduction optional messages for implicitly announcing routes added in form of complete subtrees and their attainable subtrees, although the announced distance will not match exactly that of the terminal destination, so criteria and parameters are necessary optional to configure or assume by default for the estimation of the remaining distance to the final destination depending on the difference in hierarchical levels between the final destination and the route announced. This option is important given that in networks Current Ethernet, given its high speed, metric or distance relative between route via expansion tree or alternative can be secondary compared to the main advantage of increased utilization of Network infrastructure

One more difference from the HURP protocol compared with RIP is that HURP default applies a routing through of the hierarchical tree built by CSTP (the tree formed by all the combined bridges, with the assigned HLMAC addresses) and take advantage of hierarchical addressing to always have default route in case of reconfiguration or failure of routing It also allows you to optionally reduce the number of exchanged routes That is, HURP walks through the branches transversal in a complementary way to the hierarchical tree, only when cross paths are advantageous (their calculated cost is less than or equal to the default route through the hierarchical tree or an estimate of said cost). Therefore, the announcement of transversal routes by the HURP protocol is conditioned to the probability that the advertised route is advantageous or at least equivalent to the route through the hierarchical tree.

The routes spread to each neighbor can Defer to meet the following conditions:

- Split Horizon Condition: Do not spread to the neighbor the routes learned from him.

- Prohibited Money Condition: Do not broadcast to neighboring routes that involve a prohibited turn in the network to be used by said neighbor.

Different schemes are possible in terms of diffusion that the HURP protocol of alternative routes to the exchanged from the expansion tree. An alternative of realization of route dissemination is that each node, before spreading the route to a neighbor, as with the horizon divided, it deletes from the ad the routes whose next jump implies a prohibited turn from the receiving node of the route (going through of the node announcing the route). This eliminates possible routes to some nodes, but it results in a better compromise, preferable to announce all routes and that, when the plot arrives at the node, find the turn of your next jump as forbidden and have to ascend through the tree, using in practice a longer route. This climbing mechanism by the tree in the absence of a route is important for robustness of routing.

The similarities of HURP with the RIP protocol are the message types defined (request message and the various differentiated types of response message) and which routes to subnets are broadcast to each neighbor (as is currently done in the RIPv2 version). In the case of HURP, the routes are represented by subtrees that are added hierarchically according to RSTAA coordinates and have topological significance.

Since the HURP protocol is based mainly in the distance vector algorithm used by the RIP protocol, this differentiates it from the RSJ protocol used in UETS and which is inspired by the STAR protocol cited in the background.

HURP hierarchy properties improve scalability and its distance vector algorithm It favors simplicity and robustness. Other advantages of this protocol are that it allows to use links between combined bridges that are not part of the expansion tree (i.e., links transversal), when its cost is less than the exact cost or estimated road by the expansion tree, allowing the full use of network infrastructure. In addition, the redundant links between bridges of one level and those of the immediate upper and lower, which are normally deactivated by the tree expansion protocol, can be used by HURP increasing the performance and utilization of the network. Another benefit is that HURP uses a hierarchical table instead of a table of flat distances, allowing for alternative routes of simple form.

The HURP protocol can operate by applying various routing mechanisms: vertical, transverse to neighbor and distant transverse bridge, defined as follows.

The vertical routing that HURP performs for default uses the hierarchical address tree created: the frame is routed from the origin terminal up to reach, if it is possible, a bridge whose address is the common prefix to HLMAC addresses source and destination. Bridge address combined where the HURP protocol must perform the top turn down is obtained by extracting the common prefix between HLMAC addresses source and destination. If the latter does not exist common prefix, the plot ascends to the root bridge of the tree (which is always a combined bridge) and descends the branch corresponding to your destination. This vertical routing then follow the guidelines of the standard STP protocol, but without needing frame broadcasting or learning MAC addresses employed (hierarchical).

Cross routing to neighboring bridge occurs when there is a link between two bridges that do not belongs to the expansion tree, that is, if there is a link cross linking a bridge with a neighbor, HURP can route the user frame received, upon reaching one of these bridges, to through the transverse link with the neighbor. This link or path transverse is used only in case the distance calculated for that transverse route is less than or equal to the distance across of the root bridge (the latter is the distance of the route used default, according to vertical routing).

Another way of routing is also possible transverse of a frame, which is called transverse routing  distant, when there are intermediate bridges that link through links transversal the origin and destination of the plot. The use of Distance vectors allow you to calculate the optimal routes to the bridges and determine if they are via tree or by transversal links.

Additionally, the HURP protocol uses Turn prohibition mechanisms to avoid frame loops due to temporary inconsistency of routing tables created on the combined bridges. The use of RSTCA hierarchical coordinates for turning control prevents need to execute an algorithm in the network that determines the allowed and forbidden turns, making each node in a way independent from your RSTCA address, the previous nodes and following the route and the source and destination addresses of the frame in some case. Bridges prevent executing prohibited turns to the user frames even if the route they have in the table is optimal

Since the HURP protocol assigns the node identities using the standard tree protocol of expansion, the identity of the root node / bridge is always the smallest, what which guarantees a high effectiveness in the prohibition of turns.

The hierarchical addressing of the protocol HURP confers, in front of the classic up / down routing, greater ability to discern between types of turns, introducing the concept of horizontal link, allowing some turns that the up-down routing up / down prohibits, as are the horizontal-up turns (the latter they would be considered bottom-up and therefore turns prohibited if hierarchical addresses are not used to identify the combined bridges). It is understood by link horizontal (or transverse), which goes from one node to another of the same level in the same expansion tree.

Thanks to this it is possible to reduce the turns prohibited from strict down-up turns and horizontal-horizontal allowing turns horizontal-up. In this way, while in HURP when the first link is transverse the rotation is allowed, in the classic up / down routing, where the turn only can be up-down or down-up, the turn turns out to be prohibited in the Half of the cases. On the other hand, HURP allows to establish routing mechanisms up / down more complex than in the classic, such as heading towards the expansion tree branch destination instead of the destination node strictly, which increases your flexibility and robustness of routing.

The main differences of the HURP protocol with respect to the "hierarchical" routing that exists in UETS They are:

- The "hierarchical" protocol of UETS is the known as "micro-routing" (routing classic based tables between ports linked by links that don't they belong to the hierarchical topology). In UETS it is used in switches applicable to various arbitrary network topologies by combining Banyan switching (with architecture multistage "self-routing") and the so-called "micro-routing" used in the lines of cross-sectional network connection.

- In UETS a single switch is contemplated in the simplest cases, which operates in a combined way, but between disjoint networks: a network formed by the special bridges of UETS and another network of conventional 802.1D bridges.

- In the here called combined hierarchical tree (CHT) routing by hierarchical branches uses both the expansion tree (STP or RSTP), for frames with global MAC destination (UMAC), such as hierarchical protocol (HURP), for frames with MAC hierarchical local destination (HLMAC).

The interoperability problem among two domains of Ethernet addresses (standard Ethernet and UETS) are solve here through a fully compatible scenario where network bridges co-exist that use the stack of Standard TCP / IP / Ethernet protocols in mixed 802.1D networks with 802.1D and Ethernet simultaneous functionality combined bridges hierarchical The CHT protocol builds a tree with bridges combined to which 802.1D standard expansion shafts are connected, thus forming an extended standard expansion tree. Only each root bridge of a conventional bridge tree you can join a hierarchical tree like the one that exists in UETS, by which bind completely as subtrees, from 1 to N bridges each subtree The expansion tree is used in the UETS domain, not used in native UETS mode, combining UETS and 802.1D regions freely mixed, as long as the UETS tree does not fragment, in in which case as many regions are taken as the number of UETS subtrees. The "thick trees" Ethernet traffic aggregation ("fat tree ", in English, with transmission rates of 10 Mbps, 100 Mbps, 1 Gbps and 10 Gbps are more effective than mesh networks conventional for aggregation traffic, so this Tree topology presents high efficiency.

The two protocols described, CSTP and HURP, They can be implemented as one or separately. At case of being implemented as one, the creation functions and combined bridge tree maintenance, allocation and HLMAC address reassignment and routing are integrated functionally with each other, allowing variants of operation and more integrated routing.

Another aspect of the invention relates to a subnet interconnect device (the one here called bridge combined) operating at the data link level (layer 2) according to the network protocol that creates the mixed expansion tree described previously. This device constitutes a network bridge that is autoconfigurable and is based on the operation of its ports in at least two modes, simultaneously or alternatively: in standard mode as a conventional bridge (802.1D) and in hierarchical mode operating through the HURP protocol. Optionally, a third can be added mode of operation that includes routing of the Protocol Internet (IP). This network bridge device is thus Interoperable with extended functionality of: Ethernet switch transparent, address-based switch / router Local hierarchical Ethernet and address-based router IP.

A further aspect of the invention relates to a switched network with one or more interconnection devices subnets that constitute the proposed combined network bridges and to which at least one conventional network bridge can be added that operates exclusively according to the standard 802.1D protocol.

In short, the advantages of the invention About the prior art are:

-

Front to UETS, MSTP and the IEEE proposal in 2005 under the name "Shortest Path Bridging" (http://www.ieee802.org/802_tutorials/july05/nfinn-shortest-path-bridging.pdf):  the CHT protocol and, therefore, the proposed combined bridge It is self-configuring.

-

Front to MSTP, "Shortest Path Bridging" and routers: the bridge combined has a simple structure and its construction results economic, because it uses standard hardware and is migrable via software.

-

Front to 802.1D: the combined bridges make full use of the network without links disabled, by using the links transversal in the hierarchical transversal routing.

-

Front to the classic up-down routing: the hierarchical addressing using the invention allows a more precise routing and avoids loops in a simpler way, prohibiting the turn-ups and allowing jumps from one bridge to another with a smaller prefix.

-

high scalability without the use of additional frame encapsulation.

       \ global \ parskip0.930000 \ baselineskip
    

-

Maintenance of standard mechanisms broadcast ("broadcast") and multicast ("multicast") 802.1D in OSI layer two.

-

ARP protocol support standard for resolving IP addresses to hierarchical UMAC; versus UETS that requires eDNS ("Enhanced Name Servers) Domain Naming System ").

Description of the drawings

To complement the description that is being performing and in order to help a better understanding of the characteristics of the invention, according to a preferred example of practical realization of it, is accompanied as an integral part of this description, a set of drawings where with character Illustrative and not limiting, the following has been represented:

Figure 1.- Shows a representation schematic of an example of a telecommunications network, where Tree nodes represent network bridges and connection links between nodes they represent the possible established paths.

Figure 2.- Shows a representation schematic of the CST expansion tree that, starting from the network of the previous figure is created according to a preferred embodiment of the invention.

Figure 3.- Shows the format of a frame BPDU used by the tree creation and maintenance protocol of expansion, such as that of the previous figure, according to a preferred embodiment of the invention.

Figure 4.- Shows an example of assignment hierarchical address in the expansion tree created according to a preferred embodiment of the invention.

Figure 5.- Shows an example of resolution of addresses using the ARP protocol in the expansion tree hierarchical created according to a preferred embodiment of the invention.

Figure 6.- Shows the format of a frame BPDU, containing route information, used by the protocol of creation and maintenance of an expansion tree, such as that of the previous figure, according to a preferred embodiment of the invention.

Figure 7.- Shows a block diagram of the frame forwarding process that runs on a combined bridge according to a preferred embodiment of the invention.

Figure 8.- Shows an example of routing of frames in the expansion tree, created according to a preferred embodiment of the invention, using the links (vertical) set by default in that tree.

Figure 9.- Shows an example of routing of frames in the expansion tree, created according to a preferred embodiment of the invention, using the links (transversal) that do not belong to said tree between nodes neighbors.

Figure 10.- Shows an example of routing of frames in the expansion tree, created according to a preferred embodiment of the invention, using the links (transversal) that does not belong to said tree between nodes intermediate neighbors.

Figure 11.- Shows an example of routing of frames in the expansion tree, created according to a preferred embodiment of the invention, using prohibition of turns

Detailed description of the invention

A preferred embodiment of the invention as a data link level network protocol or layer two, applicable to a telecommunications network, as you can be a campus network, represented in Figure 1 by a tree or graph, where blank nodes correspond to network bridges conventional, configured under the 802.1D standard, while the gray nodes are network bridges that operate through the protocol proposed here and named for distinction compared to conventional ones as combined bridges. This Layer two protocol, designated to abbreviate by the acronym CHT previously explained, in turn, comprises two protocols:

- CSTP protocol: creation protocol and maintenance of a mixed expansion tree consisting of bridges Conventional and combined bridges.

- HURP protocol: routing protocol and hierarchical forwarding up-down.

Conceptually, a combined bridge can be seen as a frame router with local Ethernet addresses hierarchical that incorporates the standard functionality of a bridge conventional.

       \ global \ parskip1.000000 \ baselineskip
    

In the example network of Figure 1, they are shown a series of combined bridges (R, B1, B2, B3, B4, ...) of which a root bridge (R) is chosen assuming that, by configuration of the priority of bridges, conventional and combined, the bridge R is the one that has a smaller prefix or identity number of the bridge of the whole series. From said root bridge R are constructed, As shown in Figure 2:

- the standard 802.1D expansion tree, formed by the nodes connected by links represented with thin line, Y

- the bridge expansion tree combined, consisting of gray nodes connected by links represented with thick line.

The links between nodes represented in the Figure 2 with dashed line correspond to blocked roads by the standard 802.1D protocol, while those represented with dotted line are links that serve as useful paths for the routing protocol of the combined bridges. In this tree of mixed expansion formed, the combined bridges can employ all the links that interconnect them to route frames, in addition to the paths of the hierarchical tree built exclusively with said bridges combined. In the leaves of the expansion tree mixed there are only nodes that operate in standard mode, whether bridges conventional or already combined bridges operating according to the 802.1D protocol, the latter drawn in Figure 2 as nodes gray with a blank inner circle, for example, is the case of the combined bridge B4.

Combined bridges handle the format of standard Ethernet frame, without requiring encapsulation, within the which the fields of destination MAC address and source MAC address are according to 802.1D standard, each field being defined by 48 bits grouped into 6 octets, as illustrated by an example in the following table:

one

In the first octet, number 0, of the address MAC, the 802.1D standard stable that the first bit transmitted in the network indicates:

if the value is zero, that is a individual address or "unicast";

if the value is one, that is a group address or "multicast".

In the first octet, number 0, of the address MAC, the 802.1D standard stable that the second bit transmitted in the network indicates:

if the value is zero, that is a universal or global address;

if the value is one, that is a local address

Within the standard Ethernet frame, the CHT protocol makes an assignment of the source MAC addresses and local destination hierarchically according to one of the following two alternatives:

a) No explicit prefix length: The first bit transmitted in the network contains the standard value for individual addresses and the second bit contains the standard value for local MAC addresses. The zero port identity is used to indicate the termination of the hierarchical address within 48 bits of the MAC address, so starting from the right in the following table zero octets indicate that the address is shorter than the 6 octets available for levels of addressing; they are thus octets whose value has no meaning of direction:

2

       \ newpage
    

In the previous table the address is represented MAC value 5.140.51.195.60, which corresponds to an address five levels, so the last octet, corresponding to a Level 6 sets everything to zero. The first octet has both first bits assigned with the commented standard values and the Remaining bits are used for a level 1 MAC address. This alternative offers greater addressing simplicity and greater range, although modifying the equivalence of port identities 802.1D protocol, range that starts at zero. Therefore, it increase by one to obtain the equivalent port identity in the CHT protocol and one unit is reduced the maximum number of ports per network bridge to 255 ports, that is, the range is used 1-255 instead of 0-255.

b) Explicit length: In the first octet, after the first and second bits transmitted indicating that it is an individual address and local MAC address respectively, is use the next 3 bits of said first octet to indicate the number of levels or length in address fields hierarchical, providing 0 to 7 levels available. The rest of bits, fourth to eighth bit, of the first octet are used as level 1 of the local MAC address. In this case the maximum number of ports on switches it is limited to 256, in the range of 0 to 255, of in a general way and, in particular, to 8 ports on the first level or level 1. The advantage is that the number of levels is easily configurable An example of this alternative is given in the following table:

3

       \ vskip1.000000 \ baselineskip
    

In the previous table the address is represented MAC value 5,140.51,195.60, with five levels, so in the First octet specifies that the length is 5 in a field address length formed by the underlined bits in the table.

The hierarchical allocation mechanism of directions leverages the construction of the expansion tree standard, so that the STP / RSTP expansion tree protocol extends incorporating after the last octet of a standard BPDU 6 more octets, which contain the prefix or address of the root port of the BPDU recipient bridge. Figure 3 illustrates the plot that constitutes this BPDU, indicating to the right the number of octet. Bytes 36-41 contain the address Local MAC corresponding to a port designated to connect a combined bridge given with a neighbor, which is built following the format explained above, either according to the alternative of explicit length or without explicit prefix length. He given combined bridge transmits a BPDU to all its neighbors corresponding to each designated port. The neighbors replace the Last 6 octets of the BPDU with the value of the local MAC address which corresponds to each of their respective designated ports and so, successively, these types of BPDUs are exchanged, during the operation of the CSTP protocol and once formed the STP / RSTP, to form the hierarchical tree.

Figure 4 illustrates how the assignment is hierarchical addresses, using a default configuration 8-bit mask for each level of the expansion tree from of the second level and assuming that the root bridge (R) of the tree expansion has two ports designated to two respective neighbors (C1, D1) whose identifiers / prefixes are respectively 5 and 32, for example. The identifiers of the ports of each bridge are represented in Figure 4 in binary with 4 bits. The neighboring bridge D2 connected to bridge D1 through port 0111 receives a BPDU with local MAC address of value 32.7 and also containing all the STP / RSTP protocol information. With this information you assign the address to their respective designated ports, port 0110 to bridge D3 through which it sends a BPDU with address 32.7.6 and the port 0001 to bridge D5 through which it sends a BPDU with address 32.7.1, having added at the end in the respective BPDUs the identity of the designated port. The width of the mask in bits It can depend on the level of the bridge in the expansion tree. The bridges D4 and D5 are connected by their respective ports, with 0001 and 0110 identifiers in the example, to some equipment terminals (T1, T2), which in turn finally receive the BPDUS with addresses 32.7.6.5.1 and 32.7.1.6 respectively. He bridge C1 is a leaf bridge that connects directly to two terminal equipment (T3, T4) through the designated ports, in the example, 0110 and 0001. The terminal equipment T3 receives a BPDU with local address 5.6 and the terminal equipment T4 receives another BPDU with local address 5.1, in correspondence with the prefixes of said designated ports.

When the terminal ports of a bridge combined are connected to a single terminal equipment, the port designated terminal performs the replacement of the global MAC address origin in incoming frames, data frames that can be sent by the terminal equipment to the bridge, by the hierarchical local MAC address of the designated or incoming port. In the frames back towards the terminal equipment the reverse replacement is performed, reinserting the Global MAC address universally assigned to the terminal equipment. He ARP protocol is used for the resolution of the IP address to the MAC address fully compatible, be it global or hierarchical place. An ARP of a device is shown in Figure 5 terminal (e2) to resolve the MAC address of another computer terminal (e1) and how the e2 machine obtains the local MAC address hierarchy of e1 to be able to use the routing later HURP hierarchical.

The detailed resolution process of addresses using ARP, performed to obtain MAC addresses  hierarchical premises from the destination IP address, it represented in Figure 5 pointing by means of arrows (m1, m2, m3) the sequence of messages exchanged in this mechanism. In a first exchange (m1), the terminal equipment e2 sends a message ARP protocol standard and "ARP query" type with address Destination MAC, which constitutes the broadcast address and address origin, equal to the value of the MAC address assigned to the device terminal, which in this example is a global MAC address. He "ARP query" message is transported in a frame containing the destination IP address to be resolved, that of the e1 device, together with the source IP address, that of the e2 device, this frame being disseminated to along the expansion tree across the entire switched network of bridges until reaching the destination equipment (e1) without being modified. This destination device (e1) processes the message as standard "ARP query" and start a second exchange (m2) responding with a standard message of type "ARP reply" that contains the Global MAC address of this equipment (e1). The H1 bridge connected by a terminal port to equipment e1 receives the frame with the message "ARP reply" and replace the global MAC address with the local hierarchical corresponding to that designated terminal port, in addition to recalculating the CRC of the plot so that it is correct. The frame has as its destination address the MAC of the e2 device, which can be global or local, and that is assumed global in this example. The frame is forwarded by the expansion tree to the e2 equipment, which saves it in its ARP cache, so e2 has the address MAC hierarchical of the e1 equipment for sending any frame. By Last, as the third exchange (m3), the e2 unit sends frames "unicast" to the e1 device with the destination MAC address obtained.

The HURP hierarchical routing protocol operates only on frames with MAC destination addresses local. The following describes a simplified pseudocode of the forwarding of such frames that HURP performs, where the destination local MAC address:

4

       \ vskip1.000000 \ baselineskip
    

The format of the BPDUs frames handled by the HURP protocol is the one shown in Figure 6, which has a header  which includes the fields, in this order, for: the identifier corresponding to the HURP protocol, the version of the HURP protocol and The type of message or command. After the header, this BPDU contains a maximum of 20 entries of 18 octets each defining the possible routes with the following fields, in this order:

-

"RSTCA_ {i} address" of each designated port (i = 1, 2 ...) indicating the local MAC address hierarchical destination, with the format of 6 octets and with or without its explicit prefix length;

-

"prefix length" that indicates, in 1 octet, the bit length of the most significant part, i.e., the prefix, of the hierarchical local MAC address indicated;

-

"route tag" that allows identify, in 1 octet, different origins of the routes;

-

"next jump" contains the RSTCA address of the next bridge on the route;

-

"metric", using the same metric the HURP protocol that the 802.1D standard to be able to choose alternative advantageous paths to the expansion tree and indicating the own address as one more route with zero distance.

The HURP protocol extends the RIP protocol with hierarchically assigned addresses and use a metric of IEEE 802.1D standard bridge type costs, where the vector of distance of a link is inverse to the transmission speed in said link. The shortest route or path to the destination network is established by the HURP protocol using the same by default distance vector algorithm that for bridges conventional, calculating distance as a divided constant by the capacity of the link in bits per second. The following table reproduce the link costs recommended by the IEEE standard 802.1D:

5

Forwarding frames with MAC addresses Local "unicast" destination that does the HURP protocol is displayed in Figure 7, according to the following steps:

Upon receipt of the frames (S1), the HURP protocol determines the frames for routing hierarchical (S) taking into account the extracted route information of the routing database (DB1) defined in the bridge. Simultaneously, the status of the source port (P1) and the of the destination port (P2) to execute the active topology (S2), and to then a frame filtering (S3) is performed according to the Filtering database (DB2) configured on the bridge. Both frames filtered in (S3) such as hierarchical routing (S) they pass to different tails, in a frame sizing step (S4) that takes into account the status of the source port (P1) and that of the port destination (P2). From the frame queues, the frames to transmit (S5) and then establish a priority mapping (S6). Before transmitting these frames (S8), it is done a check of said frames for errors (S7), recalculating the FCS field: "Frame Check Sequence".

The HURP protocol follows by default a scheme of vertical routing that uses the hierarchical tree of addresses created: the plot is routed from the source to up along the hierarchical tree until reaching, if it is possible, a combined bridge whose address is the common prefix to HLMAC addresses source and destination. To get that prefix common to both and therefore the direction of the bridge where to perform a top-down turn, a logical AND operation is performed between local source and destination MAC addresses; in the example of the hierarchical tree shown in Figure 8:

(32.7.6.5.1) AND (32.7.1.6) = 32.7

Figure 8 shows the route, represented by a dashed arrow, which follows a plot that starts from a team origin terminal (O), whose hierarchical local MAC address is 32.7.6.5.1, until reaching a destination terminal equipment (F), being in example 32.7.1.6 the destination local MAC address. The tree hierarchical of Figure 8 has a root bridge (R) and three bridges leaf (H1, H2, H3), where the root bridge (R) is supposed to have a prefix with value equal to 32. In this example the terminal equipment origin (O) is connected to the first leaf bridge (H1). The direction H1 hierarchical local MAC of the combined bridge H1 is 32.7.6.5 and its port designated to connect to terminal equipment OR has a identifier whose value is 1, i.e., 0001 in binary. By consequently, the source local MAC address, assigned to the computer terminal O and that replaces its universal MAC address in the routing, is 32.7.6.5.1. Following the same assignment Hierarchical and address resolution, local MAC address hierarchy of the destination terminal equipment (F) is 32.7.1.6, because it is connected by a designated port with value identifier binary 0110 to the second leaf bridge (H2) which, in turn, connects by the designated port of identifier 0001 of a bridge intermediate (BR1) of local MAC address 32.7. This BR1 bridge is the Common combined bridge between the H1 and H2 leaf bridges, where the routing protocol performs the turn of up and down.

Additionally, the HURP protocol can perform a transversal routing using the links that are left out of the established hierarchical tree. This cross routing it can occur between direct neighboring bridges, as illustrated in Figure 9, or through cross links between bridges intermediates, as illustrated in Figure 10.

Figure 9 shows the route, represented by a dashed arrow, which follows a plot that starts from a team origin terminal (O '), whose hierarchical local MAC address is 32.7.6.5.1, until reaching a destination terminal equipment (F '), being in example 32.7.1.5.0.0 the destination local MAC address. The plot sent by the originating terminal equipment (O ') connected to the port 32.7.6.5.1, upon entering the first leaf bridge (H1) with direction Local MAC 32.7.6.5, then replacing the address in the frame MAC global origin by hierarchical 32.7.6.5.1. This leaf bridge (H1) knows that there is a transverse link (A1) that connects it to a neighboring bridge (BR2) of hierarchical MAC address equal to 32.1.5.0. Since the distance to said neighboring bridge (BR2), in the  example, it is k times lower, being k configurable, with a value typical between 1 and 3, at the distance to the root bridge (R), routes the frame by the transverse link (A1), which reaches the neighboring bridge (BR2) and from there to the corresponding destination port, replacing the local MAC address in the frame with the MAC address global destination terminal equipment (F ').

Apart from transverse routing to a neighboring bridge, as in the previous case, you can also make a Distant transverse routing using intermediate bridges, such as This is the case shown in Figure 10. Figure 10 shows the route, represented by a dashed arrow, which follows a plot that part of a source terminal equipment (O ''), whose local MAC address hierarchical is 32.7.6.5.1, until you reach a destination terminal equipment (F ''), being in example 32.7.1.5.0.0 the local MAC address destination. The first leaf bridge (H1) knows that there is a bridge intermediate (BR3) that allows an advantageous route, routing the frame by the transverse link (A2) existing between said bridges H1 and BR3, to continue the road by another cross link A3 connecting said intermediate bridge (BR3) until the bridge is reached BR2 connected to the destination terminal equipment (F '').

Figure 11 represents a network with nodes hierarchically staggered according to their RSTCA coordinates, represented above each node next to the reference letter used The root bridge (R) is the origin of coordinates from which it starts the HURP protocol to determine a series of permitted turns and forbidden

In the HURP protocol, as in others turn prohibition protocols, the ban serves to avoid loops of user frames during convergence of the protocol. The standard expansion tree protocol, STP or RSTP, in itself guarantees the absence of loops during the convergence of the same by blocking the ports of the network bridges that can create loops, including all ports  designated, which are blocked, and those that are blocked by oneself protocol. But the complementary distances vector protocol use the cross links and can present, during the normal operation of the standard expansion tree protocol, transient loops during their convergence, so the Turn prohibition is necessary because it allows you to avoid loops transient user frames.

There are several alternatives regarding rules and implementation of the draft ban that, according to HURP protocol implementations, can be configurable or produce appropriate protocol variants for certain networks in depending on your topology and the administrator requirements of net. Here are described the alternatives of prohibition of turns as standard, strict, lax and routing to the branch destination.

In the standard alternative, the HURP protocol use the standard TP criteria to determine if a turn is up or down, comparing the identifiers of the three nodes of the turn, so the turn is prohibited if it is bottom-up, for example the turn formed by the three nodes (i, c, d), that is: if c> i and c> d. As HURP employs HLMAC hierarchical identifiers, the comparison of they consist in comparing the prefix lengths first, the node with the longest length of prefix. In case of the same prefix length they are compared so iterative prefix magnitudes starting with the field plus significant, this is starting from the left. In case of a tie the magnitudes of the next HLMAC field are compared and so successively. In figure 11, according to this criterion they result, by For example, node identifiers c <e and f> i.

In addition to the standard alternative, the protocol HURP, for the use of HLMAC hierarchical identifiers, introduces an alternative type of link in the protocols of prohibition of rotation: the horizontal link (the one that joins bridges with same prefix length). The horizontal type link, to combine with type links above, horizontal and below, makes possible to distinguish prohibited turns from additional types.

While in the classic routing Up-down possible turns are only from type up-down and down-up, because identifiers lack a hierarchical level, being therefore Forbidden the bottom-up, in HURP the turns Basic prohibited are: down-up, for the same up-down routing standard; down-horizontal, because followed by a horizontal-up would result in an equivalent turn bottom up; Y horizontal-horizontal because loops can be created horizontal. All other spins are allowed, including the down-down and up-down out From the tree. Examples of permitted turns in all cases in the hierarchical tree of Figure 11 are the ones given below, indicating in the left column the references given to the Tree nodes drawn in Figure 11:

a-b-f

allowed to be ascending

h1-a-b

allowed to be ascending

a-b-c

allowed to be horizontal-up

h1-a-j

allowed to be horizontal-up

B C D

allowed to be horizontal-up

c-e-h

allowed to be horizontal-down

e-h-h2

allowed to be horizontal-down

e-g-h

allowed to be horizontal-down

a-j-c

allowed to be horizontal-up

b-c-i

allowed to be horizontal-up

h1-j-h2

allowed to be up and down

       \ vskip1.000000 \ baselineskip
    

A ban can then be carried out in HURP of strict turns that simplifies the execution of the prohibition of turns as it is not necessary to analyze fields of each plot of user as the destination address. But it is also possible with HURP carry out a ban on lax turns with which it is pursued minimize the minimum number of prohibited turns to, therefore, maximize the plot possibilities of reaching the destination in Route instability situations.

Another possible variant in the version of HURP protocol with prohibition of turns referred to here routing to the target branch aims to maximize the possibilities of reaching the destination even in case of instability of routes in the nodes. For this, we try to maximize possibilities of reaching the destination branch. It is understood by branch destiny the branch of the hierarchical tree constituted by the superiors hierarchies of the destination node, that is, the bridges whose HLMAC identifier is a prefix of the HLMAC identifier of the bridge destination. Therefore, the descent is only allowed when reached the destination branch or the turn ends up reaching it. Do not up-down turns outside the tree are allowed not to go down, without being sure of reaching the destination, since no It can be uploaded on the network once it starts downloading.

Examples of permitted and prohibited turns in this variant of routing to destination branch are the following Referring to Figure 11:

r-i-c

down-down, forbidden for not being node c of target branch

f-i-e

horizontal-down, prohibited by no be j of branch destiny

       \ vskip1.000000 \ baselineskip
    

Examples of permitted and prohibited turns in the tree of Figure 11 and its reasons according to a strict version of prohibition of turns, with turns prohibited without exceptions for destination, implemented in HURP are the following:

b-c-e

forbidden for being horizontal-horizontal

c-e-g

forbidden for being horizontal-horizontal

c-e-h

allowed to be horizontal-down

r-d-c

prohibited as the node d of the destination branch (the routing once reached the destination branch must go by said branch)

i-c-e

forbidden for being down-horizontal

c-j-e

forbidden for being bottom up

       \ vskip1.000000 \ baselineskip
    

In the version of the HURP protocol with prohibition of lax turns the priority is to minimize the total number of turns prohibited, so exceptions are made if the turn is reached The target branch. Examples referred to Figure 11 are:

d-g-h

descending allowed to be branch destination

g-h-h2

descending, allowed to be branch destination

f-r-i

allowed to be destination branch

c-i-e

up-down allowed to be the destination branch r node

r-i-d

down-horizontal, allowed to be the destination branch node d

       \ vskip1.000000 \ baselineskip
    

It is understood by control plane in the routing protocols to protocol control messages exchanged between nodes, such as route information. He User plane refers to the frames sent by users and routed by the nodes.

The prohibition of turns is exercised on the user frames, preventing prohibited turns from being made in the user plane. This prevents the existence of frames circulating indefinitely or storms of frames. On the other hand, the prohibition of turns, in the control plane, affects the routing tables: the shortest route in each node must involve an allowed turn, so the route allowed in a node to a certain destination may not be the minimum but the legal minimum for that node. If only legal routes are spread between neighbors, with permitted turns, in the routing tables all the routes that appear are already legal, although they may not be minimal
Absolute

For maximum routing robustness, the Default route is through the root port to the root bridge. At the user level, the control of prohibited turns and optionally you can also implement the control of turns taking into account the HLMAC destination address of the plot in addition to the HLMAC of the three bridges involved in the turn: previous, current and next jump. This makes it possible to allow the prohibited turns whenever they finish in the destination branch of the tree regardless of the direction that those turns take.

       \ newpage
    

Examples of permitted and prohibited turns in the tree of Figure 11 and its reasons according to a lax version of Turn prohibition implemented in HURP are as follows:

b-c-e

forbidden for being horizontal-horizontal and node e is not branch destination

c-e-g

allowed to be horizontal-horizontal and node c is not branch origin

c-j-e

forbidden for being bottom up

i-c-e

forbidden for being down-horizontal

       \ vskip1.000000 \ baselineskip
    

The turns that end or begin in the terminal equipment or "hosts" in English, h1 and h2 in the figure 11, are always allowed. This is because the address the receive from the corresponding bridge to which they are connected, so which is always an uplink or downlink, which does not form part of the prohibited turns.

The "hosts" can have so many different HLMAC addresses as network interfaces connected to different bridges combined have. In the case of several links parallel between a terminal equipment and a bridge, the protocol of link aggregation operates as standard and behaves like a link only from the point of view of CSTP protocols and HURP

In this text, the word "understand" and its variants (such as "understanding", etc.) should not be interpreted excluding, that is, they do not exclude the possibility that described include other elements, steps etc.

On the other hand, the invention is not limited to the specific embodiments described here but also covers the variants that can be made by the average expert in the matter (for example, in terms of configuration criteria and size of telecommunications networks, size of structures of data, etc.), without leaving the scope of the invention to be It follows from the claims included below.

Claims (31)

1. Procedure for managing links at the data link level for telecommunications networks, which comprise a plurality of network bridges configured to exchange BPDU frames through links connecting said network bridges, where at least one expansion tree according to a standard protocol that is formed from a root network bridge (R) from which hangs at least one conventional network bridge operating according to the 802.1D protocol and said expansion tree having at least one network bridge sheet connected to a terminal equipment, characterized in that it comprises: - create a hierarchical expansion tree that form from the root network bridge (R) hanging at least one network bridge that is connected by a point-to-point link to said root network bridge (R) through a designated port and that has a hierarchical local MAC address assigned by adding a field six octets at the end of a standard BPDU frame, which indicates a number, which is variable, of expansion tree levels hierarchical and contains:

-

a port identifier of the designated port, corresponding to a level of the hierarchical expansion tree at which the network bridge that has said designated port, and

-

a prefix that is the port identifier of the root port, to which add the port identifier of the designated port;

- reconfigure the hierarchical expansion tree sending at least one BPDU frame of the TCN type and deleting the MAC address assigned to the port with the 802.1D standard; - use the ARP protocol to resolve MAC addresses with IP addresses.

         \ vskip1.000000 \ baselineskip
      

2. Link management method according to claim 1, characterized in that the expansion tree is created by the standard STP protocol. 3. Link management procedure according to claim 1, characterized in that the expansion tree is created by the standard RSTP protocol. 4. Link management method according to any of the preceding claims, characterized in that the hierarchical expansion tree joins at least one expansion tree created by the standard protocol and formed by conventional network bridges that are connected at the periphery of the mixed expansion tree forming subtrees, to form a mixed expansion tree. 5. Link management method according to any of the preceding claims, characterized in that the number of levels of the hierarchical expansion tree is explicitly indicated in a first octet of said six octet field. 6. Link management method according to any of claims 1 to 4, characterized in that the number of levels of the hierarchical expansion tree is implicitly indicated by filling with zeros from a last octet of said six octet field to an octet containing the port identifier of the designated port. 7. Link management method according to any of the preceding claims, characterized in that it additionally comprises periodically sending the BPDU frame with the six octet field added at the end and with a source MAC address that is unique and a destination MAC address that is a multicast address. 8. Procedure for routing data frames, which operates at the data link level and comprising the sending and forwarding of data frames with a destination MAC address through a designated port of a network bridge, is characterized because simultaneously: - route data frames with the MAC address destination equal to a universal MAC address using the standard 802.1D, and - route, along a route, at least one data frame with a source MAC address and with the address Destination MAC equal to a locally assigned MAC address hierarchical in a six octet field of a BPDU frame that has at least one entry of at least eighteen octets, where:

-

he six octet field indicates a number, which is variable, of levels of the hierarchical expansion tree and contains:

-

a port identifier of the designated port corresponding to a level of the hierarchical expansion tree at which the network bridge that has said designated port,

         \ newpage
      

-

a prefix to which the port's port identifier is added designated, the prefix being a port identifier assigned to a root port that establishes a path of minimum cost to the bridge of root network (R), determined the cost by a metric defined in the 802.1D standard;

-

the entry of at least eighteen octets contains:

-

he six octet field with hierarchical local MAC address assigned,

-

a prefix length indicating in a field of one octet the length in bits of the prefix contained in the hierarchical local MAC address assigned,

-

a route tag that identifies in another field of an octet a source address of a route, and

-

other six octet field indicating a next hop and in turn Contains the hierarchical local MAC address assigned to a bridge chosen to be next on the route

and because periodically sends, by a bridge of designated network, the BPDU frame with the at least one entry at Bridge chosen to be next on the route.

         \ vskip1.000000 \ baselineskip
      

9. Procedure for routing data frames according to claim 8, characterized in that the number of levels of the hierarchical expansion tree is indicated within the six octet field explicitly in a first octet of said six octet field. 10. Procedure for routing data frames according to any of claims 8 to 9, characterized in that when routing the data frame with the destination MAC address equal to a local MAC address assigned hierarchically, it makes a turn in a bridge of network whose address is the common prefix to the source and destination MAC addresses of the frame. 11. Procedure for routing data frames according to any of claims 8 to 10, characterized in that with the periodic sending of the BPDU frame a complete route is announced that includes the established network bridges, within the hierarchical expansion tree, in the hierarchically lower level and hierarchically higher level with respect to the designated network bridge. 12. Procedure for routing data frames according to any of claims 8 to 10, characterized in that with the periodic sending of the BPDU frame a route is announced only if the cost of the route is less than twice the cost of another established route from the designated network bridge to the root network bridge (R). 13. Procedure for routing data frames according to any of claims 8 to 10, characterized in that an aggregate route is announced with the periodic sending of the BPDU frame that determines a complete subtree. 14. Procedure for routing data frames according to any of claims 8 to 13, characterized in that the route belongs entirely to the hierarchical expansion tree. 15. Procedure for routing data frames according to any of claims 8 to 13, characterized in that the route includes at least one transverse link to a neighboring network bridge of the designated network bridge with respect to the hierarchical expansion tree only if the cost of that route is less than or equal to an estimated cost of a route that belongs entirely to the hierarchical expansion tree. 16. Procedure for routing data frames according to claim 15, characterized in that the neighboring network bridge is selected between an intermediate network bridge and a leaf network bridge connected to a terminal equipment. 17. Procedure for routing data frames according to any of claims 8 to 16, characterized in that when routing the data frame additionally comprises making a prohibition of turns in the hierarchical expansion tree, establishing prohibited turns that are constituted by links of a type that is selected from bottom-up, bottom-horizontal and horizontal-horizontal, with respect to said hierarchical expansion tree. 18. Procedure for routing data frames according to claim 17, characterized in that the prohibition of turns additionally comprises establishing other prohibited turns consisting of up-down links comprising at least one network bridge belonging to a branch of the expansion tree hierarchical formed by the bridges whose hierarchical local MAC address contains a prefix equal to the prefix of the destination MAC address. 19. Procedure for routing data frames according to claim 17, characterized in that the prohibition of turns additionally comprises establishing for a destination of the data frame a route that is of minimum cost and contains a minimum number of prohibited turns.

         \ newpage
      

20. Procedure for routing data frames according to any of claims 8 to 19, characterized in that the universal MAC address is a broadcast group. 21. Procedure for routing data frames according to any of claims 8 to 19, characterized in that the universal MAC address is multicast. 22. Procedure for routing data frames according to any of claims 8 to 19, characterized in that the destination MAC address is unique. 23. Network interconnection device operating at the data link level characterized in that it comprises at least one port through which it is connected to at least one network segment via a point-to-point link and comprises processing means configured to operate according to the link management procedure defined according to any one of claims 1 to 7. 24. Network interconnection device according to claim 23, characterized in that the processing means are configured to operate according to the data frame routing procedure defined according to any of claims 8 to 22. 25. Network interconnection device according to claim 24, characterized in that it has the at least one port configured in at least two modes of operation: a standard way to route through the 802.1D standard protocol data frames with a MAC address destination equal to an assigned universal MAC address, and a hierarchical way to route the frames of data with a destination MAC address equal to a MAC address Local assigned in a hierarchical expansion tree. 26. Network interconnection device according to claim 25, characterized in that the at least one port operates simultaneously in the two standard and hierarchical modes. 27. Network interconnection device according to claim 25, characterized in that the at least one port operates alternately between the standard mode and the hierarchical mode. 28. Network interconnection device according to any of claims 25 to 27, characterized in that the at least one port is configured in a third mode of operation to route the data frames using a destination address equal to an IP address. 29. Network interconnection device according to any one of claims 23 to 28, characterized in that it additionally comprises at least one port through which at least one network segment is connected via a non-point-to-point link and because said port is configured in a standard mode to route data frames with a destination MAC address equal to an assigned universal MAC address using the standard 802.1D protocol. 30. Switched telecommunications network characterized in that it comprises at least one network interconnection device defined according to any one of claims 23 to 29. 31. A switched telecommunications network according to claim 30, characterized in that it additionally comprises at least one network bridge that operates exclusively according to the standard 802.1D protocol and is connected to said network interconnection device.