RBridge Nicknames

Nicknames are 16-bit dynamically assigned quantities that act as abbreviations for RBridges’ IS-IS IDs to achieve a more compact encoding and can be used to specify potentially different trees with the same root. This assignment allows specifying up to 2**16

RBridges; however, the value 0x0000 is reserved to indicate that a nickname is not specified, the values 0xFFC0 through 0xFFFE are reserved for future specification, and the value 0xFFFF is

permanently reserved. RBridges piggyback a nickname acquisition protocol on the link state protocol (see Section 3.7.3) to acquire one or more nicknames unique within the campus.

3.7.1. Egress RBridge Nickname

There are two cases for the contents of the egress RBridge nickname field, depending on the M bit (see Section 3.4). The nickname is filled in by the ingress RBridge for TRILL Data frames and by the source RBridge for TRILL ESADI frames.

o For known unicast TRILL Data frames, M == 0 and the egress RBridge nickname field specifies the egress RBridge; that is, it specifies the RBridge that needs to remove the TRILL encapsulation and

forward the native frame. Once the egress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge.

o For multi-destination TRILL Data frames and for TRILL ESADI frames, M == 1. The egress RBridge nickname field contains a nickname specifying the distribution tree selected to be used to forward the frame. This root nickname MUST NOT be changed by transit RBridges.

3.7.2. Ingress RBridge Nickname

The ingress RBridge nickname is set to a nickname of the ingress RBridge for TRILL Data frames and to a nickname of the source RBridge for TRILL ESADI frames. If the RBridge setting the ingress nickname has multiple nicknames, it SHOULD use the same nickname in the

ingress field whenever it encapsulates a frame with any particular Inner.MacSA and Inner.VLAN value. This simplifies end node learning.

Once the ingress nickname field is set, it MUST NOT be changed by any subsequent transit RBridge.

3.7.3. RBridge Nickname Selection

The nickname selection protocol is piggybacked on TRILL IS-IS as follows:

o The nickname or nicknames being used by an RBridge are carried in an IS-IS TLV (type-length-value data element) along with a

priority of use value [RFC6326]. Each RBridge chooses its own nickname or nicknames.

o Nickname values MAY be configured. An RBridge that has been

configured with one or more nickname values will have priority for those nickname values over all Rbridges with non-configured

nicknames.

o The nickname value 0x0000 and the values from 0xFFC0 through 0xFFFF are reserved and MUST NOT be selected by or configured for an RBridge. The value 0x0000 is used to indicate that a nickname is not known.

o The priority of use field reported with a nickname is an unsigned 8-bit value, where the most significant bit (0x80) indicates that the nickname value was configured. The bottom 7 bits have the default value 0x40, but MAY be configured to be some other value.

Additionally, an RBridge MAY increase its priority after holding a nickname for some amount of time. However, the most significant bit of the priority MUST NOT be set unless the nickname value was configured.

o Once an RBridge has successfully acquired a nickname, it SHOULD attempt to reuse it in the case of a reboot.

o Each RBridge is responsible for ensuring that its nickname or each of its nicknames is unique. If RB1 chooses nickname x, and RB1 discovers, through receipt of an LSP for RB2 at any later time, that RB2 has also chosen x, then the RBridge or pseudonode with the numerically higher IS-IS ID (LAN ID) keeps the nickname, or if there is a tie in priority, the RBridge with the numerically

higher IS-IS System ID keeps the nickname, and the other RBridge MUST select a new nickname. This can require an RBridge with a configured nickname to select a replacement nickname.

o To minimize the probability of nickname collisions, an RBridge selects a nickname randomly from the apparently available nicknames, based on its copy of the link state. This random selection can be by the RBridge hashing some of its parameters, e.g., SystemID, time and date, and other entropy sources, such as those given in [RFC4086], each time or by the RBridge using such hashing to create a seed and making any selections based on pseudo-random numbers generated from that seed [RFC4086]. The random numbers or seed and the algorithm used SHOULD make uniformly distributed selections over the available nicknames.

Convergence to a nickname-collision-free campus is accelerated by selecting new nicknames only from those that appear to be

available and by having the highest priority nickname involved in a nickname conflict retain its value. There is no reason for all Rbridges to use the same algorithm for selecting nicknames.

o If two RBridge campuses merge, then transient nickname collisions are possible. As soon as each RBridge receives the LSPs from the other RBridges, the RBridges that need to change nicknames select new nicknames that do not, to the best of their knowledge, collide with any existing nicknames. Some RBridges may need to change nicknames more than once before the situation is resolved.

o To minimize the probability of a new RBridge usurping a nickname already in use, an RBridge SHOULD wait to acquire the link state database from a neighbor before it announces any nicknames that were not configured.

o An RBridge by default has only a single nickname but MAY be configured to request multiple nicknames. Each such nickname would specify a shortest path tree with the RBridge as root but, since the tree number is used in tiebreaking when there are multiple equal cost paths (see Section 4.5.1), the trees for the different nicknames will likely utilize different links. Because of the potential tree computation load it imposes, this capability

to request multiple nicknames for an RBridge should be used

sparingly. For example, it should be used at a few RBridges that, because of campus topology, are particularly good places from which to calculate multiple different shortest path distribution trees. Such trees need separate nicknames so traffic can be multipathed across them.

o If it is desired for a pseudonode to be a tree root, the DRB MAY request one or more nicknames in the pseudonode LSP.

Every nickname in use in a campus identifies an RBridge (or

pseudonode) and every nickname designates a distribution tree rooted at the RBridge (or pseudonode) it identifies. However, only a

limited number of these potential distribution trees are actually computed by all the RBridges in a campus as discussed in Section 4.5.