diff options
Diffstat (limited to 'doc/rfc/rfc6439.txt')
| -rw-r--r-- | doc/rfc/rfc6439.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc6439.txt b/doc/rfc/rfc6439.txt new file mode 100644 index 0000000..43a3604 --- /dev/null +++ b/doc/rfc/rfc6439.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Perlman +Request for Comments: 6439 Intel Labs +Updates: 6325 D. Eastlake 3rd +Category: Standards Track Y. Li +ISSN: 2070-1721 Huawei Technologies + A. Banerjee + Cisco Systems + F. Hu + ZTE Corporation + November 2011 + + + Routing Bridges (RBridges): Appointed Forwarders + +Abstract + + The IETF TRILL (TRansparent Interconnection of Lots of Links) + protocol provides least cost pair-wise data forwarding without + configuration in multi-hop networks with arbitrary topology, safe + forwarding even during periods of temporary loops, and support for + multipathing of both unicast and multicast traffic. TRILL + accomplishes this by using IS-IS (Intermediate System to Intermediate + System) link state routing and by encapsulating traffic using a + header that includes a hop count. Devices that implement TRILL are + called "RBridges" (Routing Bridges). + + TRILL supports multi-access LAN (Local Area Network) links that can + have multiple end stations and RBridges attached. Where multiple + RBridges are attached to a link, native traffic to and from end + stations on that link is handled by a subset of those RBridges called + "Appointed Forwarders", with the intent that native traffic in each + VLAN (Virtual LAN) be handled by at most one RBridge. The purpose of + this document is to improve the documentation of the Appointed + Forwarder mechanism; thus, it updates RFC 6325. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6439. + + + +Perlman, et al. Standards Track [Page 1] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Terminology and Acronyms ...................................3 + 2. Appointed Forwarders and Their Appointment ......................4 + 2.1. Appointment Effects of DRB Elections .......................5 + 2.2. Appointment and Removal by the DRB .........................5 + 2.2.1. Processing Forwarder Appointments ...................6 + 2.2.2. Frequency of Appointments ...........................7 + 2.2.3. Appointed Forwarders Limit ..........................8 + 2.3. Local Configuration Action Appointment Effects .............8 + 2.4. VLAN Mapping within a Link .................................9 + 3. The Inhibition Mechanism ........................................9 + 4. Inhibited Appointed Forwarder Behavior .........................11 + 5. Multiple Ports on the Same Link ................................12 + 6. Security Considerations ........................................12 + 7. Acknowledgements ...............................................13 + 8. References .....................................................13 + 8.1. Normative References ......................................13 + 8.2. Informative References ....................................13 + Appendix. VLAN Inhibition Example .................................14 + +1. Introduction + + The IETF TRILL (TRansparent Interconnection of Lots of Links) + protocol [RFC6325] provides optimal pair-wise data frame forwarding + without configuration in multi-hop networks with arbitrary topology, + safe forwarding even during periods of temporary loops, and support + for multipathing of both unicast and multicast traffic. TRILL + accomplishes this by using IS-IS (Intermediate System to Intermediate + System) [IS-IS] [RFC1195] link state routing and encapsulating + traffic using a header that includes a hop count. The design + + + + +Perlman, et al. Standards Track [Page 2] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + supports VLANs (Virtual Local Area Networks) and optimization of the + distribution of multi-destination frames based on VLANs and IP- + derived multicast groups. Devices that implement TRILL are called + "RBridges" (Routing Bridges). + + Section 2 of [RFC6327] explains the environment for which the TRILL + protocol is designed and the differences between that environment and + the typical Layer 3 routing environment. + + TRILL supports multi-access LAN (Local Area Network) links that can + have multiple end stations and RBridges attached. Where multiple + RBridges are attached to a link, native traffic to and from end + stations on that link is handled by a subset of those RBridges called + "Appointed Forwarders", with the intent that native traffic in each + VLAN be handled by at most one RBridge. An RBridge can be Appointed + Forwarder for many VLANs. + + The purpose of this document is to improve the documentation of the + Appointed Forwarder mechanism; thus, it updates RFC 6325. It + includes reference implementation details. Alternative + implementations that interoperate on the wire are permitted. + + The Appointed Forwarder mechanism is irrelevant to any link on which + end station service is not offered. This includes links configured + as point-to-point IS-IS links and any link with all RBridge ports on + that link configured as trunk ports. (In TRILL, configuration of a + port as a "trunk port" just means that no end station service will be + provided. It does not imply that all VLANs are enabled on that + port.) + + The Appointed Forwarder mechanism has no effect on the formation of + adjacencies, the election of the Designated RBridge (DRB) for a link, + MTU matching, or pseudonode formation. Those topics are covered in + [RFC6327]. Furthermore, Appointed Forwarder status has no effect on + the forwarding of TRILL Data frames. It only affects the handling of + native frames. + + For other aspects of the TRILL base protocol, see [RFC6325] and + [RFC6327]. Familiarity with [RFC6325] and [RFC6327] is assumed in + this document. In case of conflict between this document and + [RFC6325], this document prevails. + +1.1. Terminology and Acronyms + + This document uses the acronyms defined in [RFC6325]. + + A "trunk port" is a port configured with the "end station service + disable" bit on, as described in Section 4.9.1 of [RFC6325]. + + + +Perlman, et al. Standards Track [Page 3] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + In this document, the term "link" means "bridged LAN", that is to say + some combination of physical links with zero or more bridges, hubs, + repeaters, or the like. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. + +2. Appointed Forwarders and Their Appointment + + The Appointed Forwarder on a link for VLAN-x is the RBridge that + ingresses native frames from the link and egresses native frames to + the link in VLAN-x. By default, the DRB (Designated RBridge) on a + link is in charge of native traffic for all VLANs on the link. The + DRB may, if it wishes, act as Appointed Forwarder for any VLAN and it + may appoint other RBridges that have ports on the link as Appointed + Forwarder for one or more VLANs. + + It is important that there not be two Appointed Forwarders on a link + that are ingressing and egressing native frames for the same VLAN at + the same time. Should this occur, it could form a loop where frames + are not protected by a TRILL Hop Count for part of the loop. (Such a + condition can even occur through two Appointed Forwarders for two + different VLANs, VLAN-x and VLAN-y, if ports or bridges inside the + link are configured to map frames between VLAN-x and VLAN-y as + discussed in Section 2.4.) While TRILL tries to avoid such + situations, for loop safety there is also an "inhibition" mechanism + (see Section 3) that can cause an RBridge that is an Appointed + Forwarder to not ingress or egress native frames. + + As discussed in Section 5, an RBridge may have multiple ports on a + link. As discussed in [RFC6327], if there are multiple ports with + the same Media Access Control (MAC) address on a link, all but one + will be suspended. The case of multiple ports on a link for one + RBridge and the case of multiple ports with the same MAC address on a + link and combinations of these cases are fully accommodated; however, + multiple ports on a link for one RBridge is expected to be a rare + condition and duplicate MAC addresses are not recommended by either + TRILL or IEEE 802.1 standards. + + Appointed Forwarder status has no effect on the forwarding of TRILL + Data frames. It only affects the handling of native frames. + + + + + + + + +Perlman, et al. Standards Track [Page 4] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + There are three mechanisms by which an RBridge can be appointed or + un-appointed as Appointed Forwarder: as a result of the DRB elections + [RFC6327] as discussed in Section 2.1, as a result of action by the + DRB as discussed in Section 2.2, as a result of a local configuration + action as discussed in Section 2.3. + +2.1. Appointment Effects of DRB Elections + + When an RBridge believes that it has become the DRB on a link, by + default, it can act as Appointed Forwarder for any VLANs on that link + that it chooses as long as its port is not configured as a trunk port + and has that VLAN enabled (or at least one of its ports meets these + criteria, if it has more than one port on the link). + + An RBridge loses all Appointed Forwarder status when: + + 1. it decides that it has lost the status of being the DRB for a + link; or + + 2. it observes a change in the RBridge that is the DRB for the link + without itself becoming the DRB. + + In the rare corner case where an RBridge has more than one port on a + link, one of which was previously the DRB election winner but has + just lost the DRB election to a different port of the same RBridge + (possibly due to management configuration of port priorities), there + is no change in which RBridge is the DRB. Therefore, neither of the + above points applies and there is no change in Appointed Forwarder + status. + +2.2. Appointment and Removal by the DRB + + The DRB may appoint other RBridges on the link through inclusion of + one or more Appointed Forwarders sub-TLVs [RFC6326] in a TRILL Hello + it sends on the Designated VLAN out the port that won the DRB + election. When the DRB sends any appointments in a TRILL Hello, it + must send all appointments for that link in that Hello. Any previous + appointment not included is implicitly revoked. + + Although the DRB does not need to announce the VLANs for which it has + chosen to act as Appointed Forwarder by sending appoints for itself, + if the DRB wishes to revoke all appointments for RBridges other than + itself on the link, it is recommended that it send a TRILL Hello with + an appointment for itself for some VLAN. + + The DRB MUST NOT send any appointments on a link unless its DRB + inhibition timer (see Section 3) for that link is expired. + + + + +Perlman, et al. Standards Track [Page 5] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + How the DRB decides what other RBridges on the link, if any, to + appoint forwarder for which VLANs is beyond the scope of this + document. + +2.2.1. Processing Forwarder Appointments + + When a non-DRB RBridge that can offer end station service on a link + receives a TRILL Hello that is not discarded for one of the reasons + given in [RFC6327], it checks the source MAC address and the Port ID + and System ID in the Hello to determine if it is from the winning DRB + port. If it is not from that port, any Appointed Forwarder sub-TLVs + in the Hello are ignored, and there is no change in the receiving + RBridge's Appointed Forwarder status. Also, if no Appointed + Forwarder sub-TLVs are present in the TRILL Hello, there is no change + in the receiver's Appointed Forwarder status. + + However, if the TRILL Hello is from the winning DRB port and the + Hello includes one or more Appointed Forwarder sub-TLVs, then the + receiving RBridge becomes appointed for the VLANs that are both + listed for it in the Hello and are enabled on the receiving port. + (If the appointment includes VLAN IDs 0x000 or 0xFFF, they are + ignored, but any other VLAN IDs are still effective.) If the + receiver was Appointed Forwarder for any other VLANs, its Appointed + Forwarder status for such other VLANs is revoked. For example, if + none of these sub-TLVs in a Hello appoints the receiving RBridge, + then it loses all Appointed Forwarder status and is no longer + Appointed Forwarder for any VLAN on the port where the Hello was + received. + + The handling of one or more Appointed Forwarder sub-TLVs in a Hello + from the winning port that appoints the receiving RBridge is as + follows. An appointment in an Appointed Forwarder sub-TLV is for a + specific RBridge and a contiguous interval of VLAN IDs; however, as + stated above, it actually appoints that RBridge forwarder only for + the VLAN(s) in that range that are enabled on one or more ports that + RBridge has on the link (ignoring any ports configured as trunk ports + or as IS-IS point-to-point ports). If the RBridge was Appointed + Forwarder for any additional VLANs beyond the VLANs for which it was + being appointed, it loses Appointed Forwarder status for such + additional VLANs. + + There is no reason for an RBridge to remember that it received a + valid appointment message for a VLAN that was ineffective because the + VLAN was not enabled on the port where the message was received or + because the port was a trunk or point-to-point port. It does not + become Appointed Forwarder for such a VLAN just because that VLAN is + later enabled or the port later reconfigured. + + + + +Perlman, et al. Standards Track [Page 6] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + It should be straightforward for the DRB to send, within one Hello, + the appointments for several dozen VLAN IDs or several dozen blocks + of contiguous VLAN IDs. Should the VLANs the DRB wishes to appoint + be inconveniently distributed, for example, the proverbial case where + the DRB RB1 wishes to appoint RB2 forwarder for all even-numbered + VLANs and appoint RB3 forwarder for all odd-numbered VLANs, the + following method may be used. The network manager normally controls + what VLANs are enabled on RBridge port. Thus, the network manager + can appoint an RBridge forwarder for an arbitrary set of scattered + VLANs by enabling only those VLANs on the relevant port (or ports) + and then having the DRB send an appointment that appears to appoint + the target RBridge forwarder for all VLANs. However, for proper + operation and inter-RBridge communication, the Designated VLAN for a + link SHOULD be enabled on all RBridge ports on that link, and it may + not be desired to appoint the RBridge forwarder for the Designated + VLAN. Thus, in the general case, it would require two appointments, + although it would still only require one appointment if the + Designated VLAN were an extreme low or high value such as VLAN 0xFFE + or the default VLAN 1. + + For example, assume the DRB wants RB2 to be Appointed Forwarder for + all even-numbered VLANs and the Designated VLAN for the link is VLAN + 101. The network manager could cause all even-numbered VLANs plus + VLAN 101 to be enabled on the relevant port of RB2 and then, with the + desired effect, cause the DRB to send appointments to RB2 appointing + it forwarder for all VLANs from 1 through 100 and from 102 through + 4,094. + + Should the network manager have misconfigured the enabled VLANs and + Appointed Forwarders, resulting in two RBridges believing they are + Appointed Forwarders for the same VLAN, then item 4 in Section 3 will + cause one or more of the RBridges to be inhibited for that VLAN. + +2.2.2. Frequency of Appointments + + It is not necessary for the DRB to include the forwarder appointments + in every TRILL Hello that it sends on the Designated VLAN for a link. + For loop safety, every RBridge is required to indicate, in every + TRILL Hello it sends in VLAN-x on a link, whether it is an Appointed + Forwarder for VLAN-x for that link (see item 4 in Section 3). It is + also RECOMMENDED that the DRB have all VLANs for which end station + service will be offered on the link as well as the Designated VLAN, + enabled. Thus, the DRB will generally be informed by other RBridges + on the link of the VLANs for which they believe they are Appointed + Forwarder. If this matches the appointments the DRB wishes to make, + it is not required to re-send its forwarder appointments; however, + for robustness, especially in cases such as VLAN misconfigurations in + + + + +Perlman, et al. Standards Track [Page 7] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + a bridged LAN link, it is RECOMMENDED that the DRB send its forwarder + appointments on the Designated VLAN at least once per its Holding + Time on the port that won the DRB election. + +2.2.3. Appointed Forwarders Limit + + The mechanism of DRB forwarder appointment and the limited length of + TRILL Hellos impose a limit on the number of RBridges on a link that + can be Appointed Forwarders. To obtain a conservative estimate, + assume that no more than 1000 bytes are available in a TRILL Hello + for such appointments. Assume it is desired to appoint various + RBridges on a link forwarder for arbitrary non-intersecting sets of + VLANs. Using the technique discussed above would generally require + two appointments, or 12 bytes, per RBridge. With allowance for + sub-TLV and TLV overhead, appointments for 83 RBridges would fit in + under 1000 bytes. Including the DRB, this implies a link with 84 or + more RBridges attached. Links with more than a handful of RBridges + attached are expected to be rare. + + Note: If the Designated VLAN were an extreme low or high value, such + as VLAN 1, which is the default and may be a common value in + practice, only 6 bytes per RBridge would be required. This would + permit twice as many different Appointed Forwarder RBridges than + indicated by the general analysis above or, alternatively, would take + only half as much space to appoint the same number of Appointed + Forwarders. + + Unnecessary changes in Appointed Forwarders SHOULD NOT be made as + they may result in transient lack of end station service. Large + numbers of Appointed Forwarders on a link (in excess of 65) are NOT + RECOMMENDED due to the complexity of their establishment and + maintenance. + +2.3. Local Configuration Action Appointment Effects + + Disabling VLAN-x at an RBridge port cancels any Appointed Forwarder + status that RBridge has for VLAN-x unless VLAN-x is enabled on some + other port that the RBridge has connected to the same link. + Configuring a port as a trunk port or point-to-point port revokes any + Appointed Forwarder status that depends on enabled VLANs at that + port. + + Causing a port to no longer be configured as a trunk or point-to- + point port or enabling VLAN-x on a port does not, in itself, cause + the RBridge to become an Appointed Forwarder for the link that port + is on. However, such actions can allow the port's RBridge to become + Appointed Forwarder by choice if it is the DRB or by appointment, if + it is not the DRB on the link. + + + +Perlman, et al. Standards Track [Page 8] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + +2.4. VLAN Mapping within a Link + + TRILL Hellos include a field that is set to the VLAN in which they + are sent. If they arrive on a different VLAN, then VLAN mapping is + occurring within the link. (Such VLAN mapping within a link between + RBridges should not be confused with VLAN mapping inside an RBridge + [VLANMAP]). VLAN mapping between VLAN-x and VLAN-y can lead to a + loop if the Appointed Forwarders for the VLANs are different. If + such mapping within a link was allowed and occurred on two or more + links so that there was a cycle of VLAN mappings, a broadcast frame, + for example, would loop forever. + + To prevent this potential problem, if the DRB on a link detects VLAN + mapping by receiving a Hello in VLAN-x that was sent on VLAN-y, it + MUST make or revoke appointments so as to assure that the same + RBridge (possibly the DRB) is the Appointed Forwarder on the link for + both VLAN-x and VLAN-y. + +3. The Inhibition Mechanism + + An RBridge has, for every link on which it can offer end station + service (that is every link for which it can act as an Appointed + Forwarder), the following timers denominated in seconds: + + - a DRB inhibition timer, + + - a root change inhibition timer, and + + - up to 4,094 VLAN inhibition timers, one for each legal VLAN ID. + + The DRB and root change inhibition timers MUST be implemented. + + The loss of native traffic due to inhibition will be minimized by + logically implementing a VLAN inhibition timer per each VLAN for + which end station service will ever be offered by the RBridge on the + link; this SHOULD be done. (See the Appendix for an example + motivating VLAN inhibition timers.) However, if implementation + limitations make a full set of such timers impractical, the VLAN + inhibition timers for more than one VLAN can, with care, be merged + into one timer. In particular, an RBridge MUST NOT merge the VLAN + inhibition timers together for two VLANs if it is the Appointer + Forwarder for one and not for the other, as this can lead to + unnecessary indefinitely prolonged inhibition. In the limit, there + will be safe operations, albeit with more native frame loss than + would otherwise be required, even if only two VLAN inhibition timers + are provided: one for VLANs for which the RBridge is the Appointed + Forwarder and one for all other VLANs. At least two VLAN inhibition + + + + +Perlman, et al. Standards Track [Page 9] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + timers MUST be implemented. Where a VLAN inhibition timer represents + more than one VLAN, an update or test that would have been done to + the timer for any of the VLANs is performed on the merged timer. + + These timers are set as follows: + + 1. On booting or management reset, each port will have its own set + of timers, even if two or more such ports are on the same link, + because the RBridge will not have had a chance to learn that yet. + All inhibition timers are set to expired except the DRB + inhibition timer that is set in accordance with item 2 below. + The DRB inhibition timer is handled differently because each port + will initially believe it is the DRB. + + 2. When an RBridge decides that it has become the DRB on a link, + including when it is first booted or reset by management, it sets + the DRB inhibition timer to the Holding Time of its port on that + link that won the DRB election. + + 3. When an RBridge decides that it has lost DRB status on a link, it + sets the DRB inhibition timer to expired. + + Note: In the rare corner case where one port of an RBridge was + the DRB election winner, but later lost the DRB election to a + different port of the same RBridge on that link (perhaps due to + management configuration of port priority), neither 2 nor 3 above + applies, and the DRB timer is not changed. + + 4. When an RBridge RB1 receives a TRILL Hello asserting that the + sender is the Appointed Forwarder that either (1) arrives on + VLAN-x or (2) was sent on VLAN-x as indicated inside the Hello, + then RB1 sets its VLAN-x inhibition timer for the link to the + maximum of that timer's existing value and the Holding Time in + the received Hello. An RBridge MUST maintain VLAN inhibition + timers for a link to which it connects if it can offer end + station service on that link even if it is not currently + Appointed Forwarder for any VLAN on that link. + + 5. When an RBridge RB1 enables VLAN-x on a port connecting to a link + and VLAN-x was previously not enabled on any of RB1's ports on + that link, it sets its VLAN inhibition timer for VLAN-x for that + link to its Holding Time for that port. This is done even if the + port is configured as a trunk or point-to-point port as long as + there is some chance it might later be configured not to be a + trunk or point-to-point port. + + + + + + +Perlman, et al. Standards Track [Page 10] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + 6. When an RBridge detects a change in the common spanning tree root + bridge on a port, it sets its root change inhibition timer for + the link to an amount of time that defaults to 30 seconds and is + configurable to any value from 30 down to zero seconds. This + condition will not occur unless the RBridge is receiving Bridge + PDU (BPDUs) on the port from an attached bridged LAN. It is safe + to configure this inhibition time to the settling time of an + attached bridged LAN. For example, if it is known that Rapid + Spanning Tree Protocol (RSTP [802.1Q]) is running throughout the + attached bridged LAN, it should be safe to configure this + inhibition time to 7 seconds or, if the attached bridges have + been configured to have a minimum Bridge Hello Timer, safe to + configure it to 4 seconds. Note that, while an RBridge could + determine what version of spanning tree is running on the + physical link between it and any directly connected bridge by + examination of the BPDUs it receives, it could not tell if + inter-bridge links beyond those directly connected bridges were + running classic Spanning Tree Protocol (STP), which might require + the root change inhibition timer to be set to 30 seconds for + safety. + + 7. When an RBridge decides that one of its ports (or a set of its + ports) P1 is on the same link as another of its ports (or set of + its ports) P2, then the inhibition timers are merged to a single + set of inhibition timers by using the maximum value of the + corresponding timers. + + 8. When an RBridge decides that a set of its ports that it had been + treating as being on the same link are no longer on the same + link, those ports will necessarily be on two or more links (one + link per port in the limit). This is handled by cloning a copy + of the timers for each of the two or more links to which the + RBridge has decided these ports connect. + +4. Inhibited Appointed Forwarder Behavior + + An Appointed Forwarder for a link is inhibited for VLAN-x if: + + 1. its DRB inhibition timer for that link is not expired, or + + 2. its root change inhibition timer for that link is not expired, or + + 3. its VLAN inhibition timer for that link for VLAN-x is not + expired. + + If a VLAN-x Appointed Forwarder for a link is inhibited and receives + a TRILL Data frame whose encapsulated frame is in VLAN-x and would + normally be egressed to that link, it decapsulates the native frame + + + +Perlman, et al. Standards Track [Page 11] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + + as usual. However, it does not output it to or queue it for that + link, although, if appropriate (for example, the frame is multi- + destination), it may output it to or queue it for other links. + + If a VLAN-x Appointed Forwarder for a link is inhibited and receives + a native frame in VLAN-x that would normally be ingressed from that + link, the native frame is ignored except for address learning. + + An RBridge with one or more unexpired inhibition timers, possibly + including an unexpired inhibition timer for VLAN-x, is still required + to indicate in TRILL Hellos it sends on VLAN-x whether or not it is + Appointed Forwarder for VLAN-x for the port on which it sends the + Hello. + + Inhibition has no effect on the receipt or forwarding of TRILL Data + frames. + +5. Multiple Ports on the Same Link + + An RBridge may have multiple ports on the same link. Some of these + ports may be suspended due to MAC address duplication as described in + [RFC6327]. Suspended ports never ingress or egress native frames. + + If an RBridge has one or more non-suspended ports on a link and those + ports offer end station service, that is, those ports are not + configured as point-to-point or trunk ports, then that RBridge is + eligible to be an Appointed Forwarder for that link. It can become + Appointed Forwarder either by its choice, because it is the DRB, or + by appointment by the DRB as described in Sections 2.1 and 2.2. + + If an RBridge that is the Appointed Forwarder for VLAN-x on a link + has multiple non-suspended ports on that link, it may load share the + task of ingressing and egressing VLAN-x native frames across those + ports however it chooses, as long as there is no case in which a + frame it egresses onto the link from one port can be ingressed on + another of its ports, creating a loop. If the RBridge is the + Appointed Forwarder for multiple VLANs, a straightforward thing to do + would be to partition those VLANs among the ports it has on the link. + +6. Security Considerations + + This memo provides improved documentation of the TRILL Appointed + Forwarder mechanism. It does not change the security considerations + of the TRILL base protocol. See Section 6 of [RFC6325]. + + + + + + + +Perlman, et al. Standards Track [Page 12] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + +7. Acknowledgements + + The authors of [RFC6325] and [RFC6327], those listed in the + Acknowledgements section of [RFC6325] and [RFC6327], and Ron Bonica, + Stewart Bryant, Linda Dunbar, Les Ginsberg, Erik Nordmark, Dan + Romascanu, and Mike Shand are hereby thanked for their contributions. + +8. References + + Normative and Informative references for this document are listed + below. + +8.1. Normative References + + [802.1Q] IEEE 802.1, "IEEE Standard for Local and metropolitan + area networks - Virtual Bridged Local Area Networks", + IEEE Std 802.1Q-2011, May 2011. + + [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System + to Intermediate System Intra-Domain Routeing Exchange + Protocol for use in Conjunction with the Protocol for + Providing the Connectionless-mode Network Service (ISO + 8473)", 2002. + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", RFC 1195, December 1990. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. + Ghanwani, "Routing Bridges (RBridges): Base Protocol + Specification", RFC 6325, July 2011. + + [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and A. + Ghanwani, "Transparent Interconnection of Lots of Links + (TRILL) Use of IS-IS", RFC 6326, July 2011. + + [RFC6327] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., + and V. Manral, "Routing Bridges (RBridges): Adjacency", + RFC 6327, July 2011. + +8.2. Informative References + + [VLANMAP] Perlman, R., Dutt, D., Banerjee, A., Rijhsinghani, A., + and D. Eastlake, "RBridges: Campus VLAN and Priority + Regions", Work in Progress, October 2011. + + + + +Perlman, et al. Standards Track [Page 13] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + +Appendix. VLAN Inhibition Example + + The per-VLAN inhibition timers (or the equivalent) are needed to be + loop safe in the case of misconfigured bridges on a link. + + For a simple example, assume that RB1 and RB2 are the only RBridges + on the link, that RB1 is higher priority to be the DRB, and that they + both want VLAN 1 (the default) to be the Designated VLAN. However, + there is a bridge between them configured so that RB1 can see all the + frames sent by RB2 but none of the frames from RB1 can get through to + RB2. + + Both will think they are the DRB. RB1 because it is higher priority + even though it sees the Hellos from RB2, and RB2 because it doesn't + see the Hellos from RB1 and therefore thinks it is highest priority. + + Say RB1 chooses to act as Appointed Forwarder for VLANs 2 and 3 while + RB2 chooses to act as Appointed Forwarder for VLANs 3 and 4. There + is no problem with VLANs 2 and 4 but if you do not do something about + it, you could have a loop involving VLAN 3. RB1 will see the Hellos + RB2 issues on VLAN 3 declaring itself Appointed Forwarder, so RB1 + will be inhibited on VLAN 3. RB2 does not see the Hellos issued by + RB1 on VLAN 3, so RB2 will become uninhibited and will handle VLAN 3 + native traffic. + + However, this situation may change. RB2 might crash, the bridge + might crash, or RB2 might be reconfigured so it no longer tried to + act as Appointed Forwarder for VLAN 3, or other issues may occur. + So, RB1 has to maintain a VLAN 3 inhibition timer, and if it sees no + Hellos from any other RBridge on the link claiming to be Appointed + Forwarder for VLAN 3 in a long enough time, then RB1 becomes + uninhibited for that VLAN on the port in question and can handle end + station traffic in VLAN 3. + + + + + + + + + + + + + + + + + + +Perlman, et al. Standards Track [Page 14] + +RFC 6439 RBridges: Appointed Forwarders November 2011 + + +Authors' Addresses + + Radia Perlman + Intel Labs + 2200 Mission College Blvd. + Santa Clara, CA 95054 USA + + Phone: +1-408-765-8080 + EMail: Radia@alum.mit.edu + + + Donald Eastlake 3rd + Huawei Technologies + 155 Beaver Street + Milford, MA 01757 USA + + Phone: +1-508-333-2270 + EMail: d3e3e3@gmail.com + + + Yizhou Li + Huawei Technologies + 101 Software Avenue, + Nanjing 210012, China + + Phone: +86-25-56622310 + EMail: liyizhou@huawei.com + + + Ayan Banerjee + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 USA + + Phone: +1-408-333-7149 + EMail: ayabaner@cisco.com + + + Fangwei Hu + ZTE Corporation + 889 Bibo Road + Shanghai 201203 + China + + Phone: +86-21-68896273 + EMail: hu.fangwei@zte.com.cn + + + + + +Perlman, et al. Standards Track [Page 15] + |