Optimization for trill LAN hellos

Systems and methods may be provided embodying an optimized Trill LAN network hello mode. The optimized hello mode may allow the number of LAN hellos exchanged to be reduced significantly in a steady state mode of operation. No modifications to the current Trill specification are needed and in a converged state (when designated RBridge election and appointed forwarder appointments are complete), only 1 hello PDU per RBridge is originated in every hello interval.

BACKGROUND

Current Trill specification (RFC 6325—“Routing Bridges (RBridges): Base Protocol Specification”, hereby incorporated by reference in its entirety) requires Trill compliant RBridges to send multiple hellos on each interface, on a subset of enabled vlans. Specifically, depending on the appointed forwarder and the role or lack thereof of the designated RBridge, nodes must send out hellos on the following vlans, where announcing vlans are a subset of the enabled vlans on the network

If the sender is a designated RBridge, hellos must be sent to the intersection set of 1) the enabled vlans and 2) the union of (designated vlan, announcing vlans). If the sender is not a designated RBridge, hellos must be sent to the intersection set of 1) the enabled vlans and 2) the union of (designated vlan, intersection of (forwarding vlans, announcing vlans).

Based on these current stipulations, in the case where a LAN has several thousand vlans in active use, at a minimum the appointed forwarders will need to send out hellos on all of the vlans for which they are the appointed forwarder. This leads to a situation where the CPU (control plane) needs to send out thousands of hellos per interface on several hundred interfaces. This situation leads immediately to a scale problem. There exists a need for the optimization of Trill LAN Hellos.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Consistent with embodiments of the present disclosure, systems and methods are disclosed for operation of a Trill LAN network using optimized hello mode. For example, a method is disclosed comprising achieving steady state converged operation on a Trill LAN network and entering a plurality of nodes into an optimized hello mode, wherein optimized hello mode requires that the plurality of nodes only send hellos on a currently designated vlan and that no appointed forwarder inhibition hellos are exchanged.

In some embodiments, one of the plurality of nodes is a designated RBridge that enters into optimized hello mode when one or more appointed forwarder appointments have been identified. The method may further comprise waiting for a first stabilization interval before entering the designated RBridge into optimized hello mode. In some embodiments, the designated RBridge may include appointed forwarder appointments in every hello.

In other embodiments, one of the plurality of nodes is an appointed forwarder that enters into optimized hello mode upon receipt of appointed forwarder appointments and the expiration of a plurality of inhibition timers have expired.

Similarly, one of the plurality of nodes may be a node that is not a designated Rbridge and is not an appointed forwarder, and the one of the plurality of the nodes may enter into optimized hello mode upon seeing appointed forwarder inhibition hellos originating from an appointed forwarder's appointees.

Some embodiments disclose Trill network node comprising a memory and a processor coupled to the memory, wherein the processor is operative to: enter the network node into an optimized hello mode; and exit the network node from the optimized hello mode upon detection of predetermined conditions.

The network node may be a designated RBridge that exits from optimized hello mode when the designated RBridge sees a hello from a new neighbor node and the designated RBridge is on a vlan that is present in an enabled-vlans set stored in the memory. Furthermore optimized hello mode may be exited immediately upon determining that the new neighbor node has a higher designated RBridge priority than the network node. Optimized hello mode may be maintained upon determining that the new neighbor node has a lower or equal designated RBridge priority than the network node.

In some embodiments, the network node is an appointed forwarder that exits from optimized hello mode when an inbound hello is seen on a vlan in the appointed forwarder's enabled-vlan set stored in the memory and when a neighbor node responsible for the inbound hello has a higher designated RBridge priority than the network node. The neighbor node may then be regarded as the new designated RBridge and the network node may relinquish the status as an appointed forwarder.

Similarly, the network node may be a node that is not a designated Rbridge and is not an appointed forwarder, and wherein the network node exits optimized hello mode upon receiving a hello from a new neighbor node on a locally enabled vlan and when the new neighbor node has a designated RBridge priority higher than the priority of a currently designated RBridge.

Some embodiments of the present disclosure disclose a method comprising: entering a plurality of Trill LAN network nodes into an optimized hello mode; detecting the failure of one of the plurality of network nodes; and responding to the network node failure based on the role of the network node.

If the failed node does not have a role as a designated Rbridge or an appointed forwarder, no action may be taken upon detection of node failure. Alternatively, if the failed node has a role of an appointed forwarder, the method may further comprise: detecting that a hello on the desired designated vlan from the appointed forwarder is timing out; re-running an appointed forwarder appointment algorithm; and exiting optimized hello mode.

If the failed node has a role of a designated RBridge, the method may further comprise: detecting that the hold-time of an adjacency with the designated RBridge is expiring; relinquishing the role of a plurality of appointed forwarders; and electing a new designated RBridge.

It is to be understood that both the foregoing general description and the following detailed description are examples and explanatory only, and should not be considered to restrict the application's scope, as described and claimed. Further, features and/or variations may be provided in addition to those set forth herein. For example, embodiments of the present disclosure may be directed to various feature combinations and sub-combinations described in the detailed description.

DETAILED DESCRIPTION

Embodiments of the present disclosure propose an optimization, where in a Trill LAN network, once steady state converged operation is achieved, nodes will only send Hellos on the current designated vlan and no appointed forwarder inhibition hellos are exchanged. The current designated vlan may be the current designated RBridge's desired designated vlan.

Rules are disclosed herein for use when nodes in the network may enter the optimized hello mode of operation. Similarly operational rules may be described for the exit from the optimized hello mode of operation for safe operation of the Trill protocol per specification.

FIG. 1is a block diagram illustrating an operating environment for providing optimized hello mode. A Trill network may comprise a number of network nodes communicating to one another through a network, such as Ethernet cloud110.

Such network nodes may include RBridge nodes such as RBridge120and RBridge130. Generally, routing bridges (RBridges) provide optimal pair-wise forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multipathing of both unicast and multicast traffic. They achieve these goals using IS-IS routing and encapsulation of traffic with a header that includes a hop count.

RBridges are compatible with IEEE 802 customer bridges as well as IPv4 and IPv6 routers and end nodes. They are as invisible to current IP routers as bridges are and, like routers, they terminate the bridge spanning tree protocol.

The design supports VLANs and the optimization of the distribution of multi-destination frames based on VLAN ID and based on IP-derived multicast groups. It also allows unicast forwarding tables at transit RBridges to be sized according to the number of RBridges (rather than the number of end nodes), which allows their forwarding tables to be substantially smaller than in conventional bridges.

Trill network may include a plurality of other connected nodes. For example, node140may be an RBridge designated as an appointed forwarder node. Any number of other nodes may exist within the Trill network and the figure is for example purposes only and should not be construed as limiting to the described embodiments of this disclosure.

FIG. 2illustrates embodiments of entry into the optimized-hello mode. It should be understood that nodes may enter the optimized hello mode at appropriate triggers depending on the particular node's role. Method200may begin at step210where at the designated RBridge, optimized-hello mode may be entered when the appointed forwarder appointments have been identified and an additional stabilization interval of X seconds has passed. In some embodiments, as an additional safeguard, the protocol may require that the designated RBridge include appointed forwarder appointments in every hello.

Method200may then proceed to step220. At step220, the appointed forwarder may enter optimized hello mode when appointed forwarder appointments have been received and the inhibition timers have expired (as the appointed forwarder appointment has been enacted in hardware). The appointed forwarder may also have to wait for an additional stabilization interval of Y seconds has expired.

Next, method200may proceed to step230where other nodes on the network (such as non-designated RBridges and non-appointed forwarders) may enter the optimized hello mode. These other nodes may enter the optimized hello mode when they see appointed forwarder-inhibition hellos originating from the appointed forwarder's appointees. The appointees may indicate the forwarding vlans. The other nodes may also have to wait for an additional stabilization interval of Z seconds has expired. In some embodiments, X>Y>Z for the duration of the stabilization intervals.

RBridges may need to exit the optimized hello mode when there is a churn in the network, and when certain triggers may be detected. Upon exit from the optimized hello mode, nodes may resume normal hello operations as outlined in the Trill protocol specification.

FIG. 3illustrates embodiments of exit from the optimized-hello mode. Method300may begin at step310where at the designated RBridge, optimized-hello mode may be exited when the designated RBridge sees a hello from a new neighbor and is on a vlan that is present in the enabled-vlans-set on the designated RBridge.

If the designated RBridge priority of the new neighbor is higher than the current designated RBridge priority, then the current designated RBridge must exit optimized hello mode immediately. Furthermore, if the designated RBridge sees its appointed forwarder appointees sending inhibition hellos, the designated RBridge must exit optimized hello mode immediately.

Alternatively, if the designated RBridge priority of the new neighbor is lower than or equal to the current designated RBridge priority, then the designated RBridge does not exit optimized hello mode. However, the designated RBridge must send additional hellos on the vlan of the newly received hello. These hellos may reflect current appointed forwarder appointments. These additional hellos may be stopped after the state of the adjacency with the new neighbor goes to 2-way or beyond.

Method300may proceed to step320where triggers may be monitored at the appointed forwarder RBridge. For example, if an inbound hello is seen on a vlan in the appointed forwarder node's enabled vlan set and if the designated RBridge priority of the new neighbor is higher than that of the current designated RBridge priority, the node must exit optimized hello mode immediately. This may also cause the current designated RBridge to exit optimized hello mode.

Furthermore, Trill allows the current appointed forwarder to regard the new neighbor (with higher designated RBridge priority) as the new designated RBridge immediately regardless of which vlan the new neighbor's hello was received on. In some embodiments, the new neighbor's hello does not have to be on the current designated vlan. Once the appointed forwarder sees a new designated RBridge, the appointed forwarder must relinquish its role immediately. This role change may be flagged in its subsequent hellos as the node has now exited optimized hello mode and the current designated RBridge will recognize this as well. Whether the current designated RBridge sees the new neighbor may depend on whether their enabled-vlan sets overlap.

If the inbound hello is seen on a locally enabled vlan and if the designated RBridge priority of the new neighbor is equal to or lower than that of the current designated RBridge, the appointed forwarder node may continue to operate in optimized hello mode. However, the appointed forwarder node must originate a few inhibition hellos on any of its forwarding vlans to force the designated RBridge to exit optimized hello mode. This covers the possibility that the current designated vlan may not be enabled on the new neighbor but some other vlan in the designated RBridge's announcing set may be enabled on the neighbor. In effect, this forces the new neighbor to sync up with the designated RBridge's current appointments. The additional inhibition hellos can be terminated when the designated RBridge's hellos are seen on vlans other than the currently designated vlan, bearing appointed forwarder appointments.

If an appointed forwarder RBridge sees hellos on vlans other than the current designated vlan from nodes which it knows are neither appointed forwarders for any vlan nor the designated RBridge, then the appointed forwarder RBridge must exit optimized hello mode immediately.

Method300may proceed to step330where other nodes on the network (such as non-designated RBridges and non-appointed forwarders) operating in the optimized hello mode may be monitored for triggers. For example, if a hello is received from a new neighbor on a locally enabled vlan and if the designated RBridge priority of that node is higher than the priority of the currently designated RBridge, then the other node must exit optimized hello mode immediately. Per Trill operation, the node will regard the new neighbor as the designated RBridge and switch to its designated vlan. Furthermore, the node may be appointed as the appointed forwarder in the near future.

FIG. 4illustrates embodiments of dealing with a node going down in embodiments of the present disclosure. It may be realized that a node has gone down when the hold time of the adjacency with that neighbor expires, which in turn is driven by hellos from that node on the desired designated vlan.

Method400may start at step410where it is detected that a non-designated RBridge or a non-appointed forwarder has gone down. No action is required in this instance. Method400may then proceed to step420when it is detected that an appointed forwarder has gone down.

At step420, the designated RBridge must now realize the failure when the hello on the desired designated vlan from the appointed forwarder starts timing out. The designated RBridge may then re-run the appointed forwarder appointment algorithm when this happens. When this occurs, the optimized hello mode must be exited immediately. Cases where an appointed forwarder reflects its appointed forwarder status incorrectly in hellos, by claiming the appointed forwarder for vlans that the designated RBridge did not assign it, may be treated similarly. After the designated RBridge elections and appointed forwarder appointments are complete, a fresh attempt to enter optimized hello mode may be made after suitable stabilization intervals using the entry criteria described above.

Method400may then proceed to step430. At step430, it may be detected that a designated RBridge has gone down. The currently appointed forwarder appointees may recognize that the designated RBridge has gone down by monitoring the hold-time of their adjacency with the designated RBridge expiring. The adjacency may be a pseudo-node adjacency or a regular one. When the adjacency expires, appointed forwarders must relinquish their role as appointed forwarders and elect a new designated RBridge. Optimized hello mode must be exited immediately when this occurs. After the designated RBridge elections and appointed forwarders appointments are complete, a fresh attempt may be made to enter optimized hello mode after suitable stabilization intervals using the entry criteria described above.

In some embodiments, Trill nodes may be configured with a default announcing set consisting of a first vlan. The first vlan will be enabled by default on all devices as the default (desired) designated vlan. This may result in plug-and-play functionality for users where operation occurs without user intervention such that there are minimal hellos exchanged.

FIG. 5is a block diagram of a system including network node120. Consistent with embodiments of the present disclosure, the aforementioned memory storage and processing unit may be implemented in a network device, such as network device120ofFIG. 1. Any suitable combination of hardware, software, or firmware may be used to implement the memory storage and processing unit. For example, the memory storage and processing unit may be implemented with network device120or any of other network devices418, in combination with network device120. The aforementioned system, device, and processors are examples and other systems, devices, and processors may comprise the aforementioned memory storage and processing unit, consistent with embodiments of the present disclosure.

With reference toFIG. 5, a system consistent with embodiments of the present disclosure may include a network device, such as network device120. In a basic configuration, network device120may include at least one processing unit502, a secure processing unit for decryption520, and a system memory504. Depending on the configuration and type of network device, system memory504may comprise, but is not limited to, volatile (e.g., random access memory (RAM)), non-volatile (e.g., read-only memory (ROM)), flash memory, or any combination. System memory504may include operating system505, one or more programming modules506, and may include program data507. Operating system505, for example, may be suitable for controlling network device120's operation. Furthermore, embodiments of the present disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated inFIG. 5by those components within a dashed line508.

Network device120may have additional features or functionality. For example, network device120may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated inFIG. 5by a removable storage509and a non-removable storage510. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory504, removable storage509, and non-removable storage510are all computer storage media examples (i.e., memory storage.) Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by network device120. Any such computer storage media may be part of device120. Network device120may also have input device(s)512such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc. Output device(s)514such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used.

As stated above, a number of program modules and data files may be stored in system memory504, including operating system505. While executing on processing unit502or secure processing unit for decryption520, programming modules506may perform processes including, for example, one or more method200,300, or400's stages as described above. The aforementioned process is an example; processing unit502and secure processing unit for decryption520may perform other processes.

Generally, consistent with per-subscriber stream management according to embodiments of this invention, program modules may include routines, programs, components, data structures, and other types of structures that may perform particular tasks or that may implement particular abstract data types. Moreover, embodiments may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. Embodiments of the present disclosure may also be practiced in distributed network environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed network environment, program modules may be located in both local and remote memory storage devices.