TRILL Working Group H. Zhai Internet-Draft F. Hu Intended status: Standards Track ZTE Expires: November 16, 2012 R. Perlman Intel Labs D. Eastlake 3rd Huawei MAY 15, 2012 RBridge: Pseudo-Nickname draft-hu-trill-pseudonode-nickname-02 Abstract At the edg of TRILL campus, some RBridges provide end-station services to their attached end stations, these RBridges are called edge RBridges. To avoid potential frame duplication or loops in TRILL campus, only one edge RBridge is permitted to provide end- station services in a VLAN x at all times for its attached end stations. However, in some application scenarios, for example in Link Aggregation Group (LAG), more than one edge RBridge is required to provide end-station services to an end stations even in a VLAN, which causes the flip-flopping of the egress RBridge nickname for such an end node in remote RBridges' forwarding tables if nothing to do. In this document, the concept of Virtual RBridge, along with its pseudo-nickname, is introduced to fix the above problem. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 16, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the Zhai, et al. Expires November 16, 2012 [Page 1] Internet-Draft Pseudo-Nickname MAY 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . . 4 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Appointed Forwarders on Shared Links . . . . . . . . . . . 4 2.2. Multi-homing and Link Aggregation to TRILL Network . . . . 5 3. Concept of Virtual RBridge and Pseudo-nickname . . . . . . . . 6 3.1. VLAN-x Appointed Forwarder for member interfaces in RBv . 7 3.2. Announcing Pseudo-Nickname of RBv . . . . . . . . . . . . 7 4. Distribution Trees for Member RBridges in RBv . . . . . . . . 7 5. Frame Processing . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.1. Native Frames Ingressing . . . . . . . . . . . . . . . 8 5.1.2. TRILL Data Frames Egressing . . . . . . . . . . . . . 9 5.1.2.1. Unicast TRILL Data Frames . . . . . . . . . . . . 9 5.1.2.2. Multi-Destination TRILL Data Frames . . . . . . . 10 5.2. OAM Frames . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhai, et al. Expires November 16, 2012 [Page 2] Internet-Draft Pseudo-Nickname MAY 2012 1. Introduction The IETF TRILL protocol [RFC6325] provides optimal pair-wise data frame forwarding without configuration, safe forwarding even during periods of temporary loops, and support for multi-pathing of both unicast and multicast traffic. TRILL accomplishes this by using [IS-IS] [RFC1195] link state routing and encapsulating traffic using a header that includes a hop count. The design supports VLANs and optimization of the distribution of multi-destination frames based on VLANs and IP derived multicast groups. Devices that implement TRILL are called RBridges. In TRILL protocol, RBridges are identified by nicknames (16-bits). Different RBridge has different nickname(s). At the edge of TRILL network, some RBridges connect to legacy networks on one side and to TRILL network on the other side. These RBridges are called edge RBridges. For the connectivity between the two types of network, edge RBridges provide end-station services to end stations located in legacy networks. When receiving a native frame from such a local end station S, the servicing edge RBridge RB1 encapsulates the frame in a TRILL header, addressing the packet to RBridge RB2 which the destination end station D is attached to. The TRILL header contains an "ingress RBridge nickname" field (RB1's nickname), an "egress RBridge nickname" field (RB2's nickname), and a hop count. On receiving such a frame, RB2 removes the TRILL header and forwards it onto D in its native form. Meanwhile, based on the de-capsulation of such a frame, RB2 learns the (ingress RBridge nickname, source MAC address, VLAN ID) triplet. Edge RBridges maintain such triplets in their forwarding table for the potential following transmission of native frames. Due to failures, reconfiguration and other network dynamics, servicing edge RBridge for S may change, i.e., no longer is RB1. In this event, remote traffic addressed to S will be still forwarded to RB1 by remote RBridge RB2 before perceiving this change, and then the traffic gets dropped at R1, causing traffic disruption. Furthermore, to improve resiliency and maximize the available network bandwidth, an end station typically is multi-homed to several edge RBridges and treats all the uplink links as a Link Aggregation Group (LAG) buddle. In this scenario, all those edge RBridges work in an active-active load sharing model to provide end-station services for an end station even in same VLAN. When remote RBridge RB2 receives different frames, which are originated by such an end station S and ingressed into TRILL campus by different such edge RBridge, flip-flopping of ingress RBridge nickname for MAC of S will be observed by RB2 during de-capsulating such frames. This flip-flopping will cause disorder of different frames in traffic, worsening the traffic disruption. Zhai, et al. Expires November 16, 2012 [Page 3] Internet-Draft Pseudo-Nickname MAY 2012 In this document, concept of Virtual RBridge group, together with its Pseudo-nickname, is introduced to address the above issues. For a member RBridge in such a group, it uses the pseudo-nickname of this group, instead of its own device nickname, as ingress RBridge nickname when encapsulating a frame to its TRILL form with a TRILL header. So, in a RBridge Group, even if there are more than one RBridge providing end-station services for a end station or the servicing RBridge changes over from one member RBridge to another in same set of VLANs, the ingress RBridge nickname for the MAC of this end station will still remain unchanged in remote RBridges' forwarding tables. This document is organized as following: Section 2 is problem statement, which describes why virtual RBridge and its pseudo- nickname are required. Section 3 gives the concept of virtual RBridge. Section 4 describes the consideration for pseudo-nickname used in ingressing multi-destination frames. Section 5 covers processing of transit frame traffic when considering pseudo-nickname. Familiarity with [RFC6325] is assumed in this document. 1.1. Terminology and Acronyms This document uses the acronyms defined in [RFC6325] and the following additional acronym: AF - Appointed Forwarder The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. When used in lower case, these words convey their typical use in common language, and are not to be interpreted as described in [RFC2119]. 2. Problem Statement 2.1. Appointed Forwarders on Shared Links In TRILL, RBridges can co-exist with legacy bridges in a traditional Ethernet. A set of links connected by bridges will be perceived by RBridges as a single shared link connecting the RBridges on that link. If there are multiple RBridges on a shared link, together with end stations, only one RBridge is permitted to provide end-station services in a VLAN x at all times for the end stations to avoid possible frame duplication or loops in TRILL campus. The service Zhai, et al. Expires November 16, 2012 [Page 4] Internet-Draft Pseudo-Nickname MAY 2012 RBridge is called VLAN-x Appointed Forwarder (AF) on a shared link. However, AF for any set of VLANs on a shared link may change over from one RBridge to another, due to failure, configurations and other network dynamics, etc. If such change occurs, local end stations may not perceive it, so the end station cannot timely notify remote RBridges to update the correspondence between ingress RBridge nickname and the MAC of this end station in their forwarding tables. As a result, remote RBridges may continue to forward traffic to the previous AF and the traffic may be dropped at the previous egress RBridge, causing traffic disruption. 2.2. Multi-homing and Link Aggregation to TRILL Network In order to improve the reliability of connection to TRILL network, multi-homing technique may be employed by a legacy device, such as a switch or end host. For example, in Figure 1, switch SW1 multi-homes to TRILL network by connecting to both RBridge RB1 and RB2 with respective links. Then the end stations (e.g., S1), attached to SW1, still get end-station services from TRILL network even if one connection of SW1 to TRILL network, e.g., SW1-RB1, fails. That is to say, the service RBridge for S1 changes over from RB1 to RB2 after the connection of SW1-RB1 fails, which causes traffic disruption temporarily (e.g., traffic from Sx to S1), similar to AF changing in Section 2.1. .......................................... : TRILL Network : : +-----+ /\-/\-/\-/\-/\ : +------| RB1 |-----/ \ : | : +-----+ / \ : +-----+ : | / Transit \ +-----+ : S1 o--| SW1 | : | < RBridges >---| RBx |---o Sx +-----+ : | \ Campus / +-----+ : | : +-----+ \ / : +------| RB2 |-----\ / : : +-----+ \/\-/\-/\-/\-/ : : : ........................................... Figure 1 Multi-homing to TRILL Network Furthermore, SW1 may treat the two links as a LAG (Link Aggregation Group) bundle, so that the two links form active-active load sharing model instead of previous active-stanby model. That is to say, in Figure 1, two service RBridges (e.g., RB1 and RB2) provide end- station services simultaneously to S1 in that VLAN. And this will Zhai, et al. Expires November 16, 2012 [Page 5] Internet-Draft Pseudo-Nickname MAY 2012 result in flip-flopping of the ingress RBridge for the MAC of S1 in remote RBridges' (e.g., RBx) forwarding tables. AS a result, this flip-flopping will cause much more disorder packets and worsen the traffic disruption. Besides switches, end stations can also directly multi-home to TRILL network and treat the multi-homing links as a LAG bundle. The issue of traffic disruption also occurs in this scenario if such an end station balances different traffic load in a same VLAN among the member links. In the following sections, concept of RBridge Group, together with its nickname, is introduced to fix these issues. 3. Concept of Virtual RBridge and Pseudo-nickname A Virtual RBridge (RBv) represents a group of different ports on different edge RBridges, on which these RBridges end-station service provide to a set of their attached end stations. After joining RBv, such an RBridge port is called a member port of RBv, and such an RBridge becomes a member RBridge of RBv. in TRILL campus, an RBv is identified by its virtual nickname in TRILL campus, and virtual nickname is also described as pseudo-nickname in this specification. After joining an RBv, a member RBridge will announce its connection to RBv by including the information of this RBv, e.g., the pseudo- nickname of RBv, in its self-originated LSP. From such LSPs, a remote RBridge that is not a member of RBv can obtain that, through one or more of such member RBridges, one or more shortest paths are available from itself to RBv by running Shortest-Path-First (SPF) algorithm. When receiving a native frame on such a port, the member RBridge uses the RBv's nickname, instead of its own nickname, as ingress nickname in TRILL header if necessary to encapsulate the frame into TRILL data form. By de-capsulating such a TRILL-encapsulated data frame, a remote RBridge learns that S is reachable through RBv. NOTES: An RBridge port can join at most one RBv at any time, but different ports on the same RBridge can join the same RBv or different RBvs. After joining an RBv, such a port becomes a member port of the RBv, and the RBridge becomes a member RBridge of the RBv. Furthermore, for a member RBridge, it MUST move out of RBv and clear the RBv's information from its self-originated LSPs when it loses the last member port from this group, due to port down, configuration, etc. Zhai, et al. Expires November 16, 2012 [Page 6] Internet-Draft Pseudo-Nickname MAY 2012 3.1. VLAN-x Appointed Forwarder for member interfaces in RBv If member RBridges in RBv cannot see each others' Hellos on their member interfaces (e.g., in the LAG scenario), then each RBridge becomes Designated RBridge (DRB) for that interface and appoints itself as AF for all VLANs as it does not see any TRILL hellos on that interface. However, if they can see each others' Hellos on the member interfaces in RBv (e.g., in the shared link scenario), the TRILL Hello protocol in RFC 6325 is used for DRB election and for VLAN-x AFs appointment for those interfaces. Then the DRB appoints different member interfaces as AFs for different VLANs. Among the member RBridges of RBv, when receiving a local native frame in VLAN-x, only the AF for this VLAN can ingress the frame into TRILL campus if necessary. However, in this specification, when receiving a TRILL data frame addressed to RBv, an member RBridge that is not AF for the inner VLAN of the frame can de-capsulate the frame and forward it in native form directly to the destination end station. 3.2. Announcing Pseudo-Nickname of RBv Each member RBridge advertises the RBv's pseudo-nickname using the nickname sub-TLV [rfc6326bis], along with its regular nickname or nicknames, in its LSPs. When a member RBridge leaves from RBv due to losing its last member ports in RBv, it MUST clear RBv's pseudo- nickname from its LSPs. 4. Distribution Trees for Member RBridges in RBv In TRILL, RBridges use distribution trees to forward multi- destination frames. When a native frame either to destinations whose location is unknown or to multicast/broadcast groups is necessary to be ingressed into TRILL campus, the ingress RBridge encapsulates it into multi-destination TRILL data frame with a TRILL header and forwards the TRILL frame along a chosen distribution tree. In the TRILL header, the ingress nickname identifies the ingress RBridge, the egress nickname represents the root of the chosen tree. After receiving a multi-destination TRILL data frame, the RBridge performs Reverse Path Forwarding (RPF) check, along with other checks, on the multi-destination frame to further control potentially looping traffic. RPF specifies that a multi-destination TRILL data frame ingressed by an RBridge and forwarded along a distribution tree can only be received by an RBridge from an expected port. If not from that port, Zhai, et al. Expires November 16, 2012 [Page 7] Internet-Draft Pseudo-Nickname MAY 2012 this frame MUST be dropped by the receiving RBridge. However, member RBridges in RBv employs RBv's pseudo-nickname other than their own nicknames as ingress nickname when they ingress a native frame, regardless unicast or multicast frame, into TRILL campus. So if different member RBridges chose same distribution tree(s) to forward different multi-destination TRILL data frames, these frames may reach a remote RBridge from different ports, which violates the RPF check. Then some of these frames will be dropped by the remote RBridge. To fix the above issue, a scalable and resilient approach is proposed in [cmt], where different member RBridges are assigned different distribution trees for forwarding the multi-destination TRILL data frames that using RBv's pseudo-nickname as ingress nickname in their TRILL header. And a new TLV, named Affinity sub-TLV, is also introduced for a member RBridge to announce its assigned distribution tree for RBv in its self-originated LSPs. After receiving such LSPs, a remote RBridge can calculate RPF check information for RBv on those specified trees. In this specification, the approach proposed in [cmt] is employed for RBv to assign different distribution trees to different member RBridges (more exactly, to member ports on different member RBridges) and for these members to announce their assigned trees in LSPs. 5. Frame Processing Although, there are five types of Layer 2 frames in [RFC6325], e.g., native frame, TRILL data frame, TRILL control frames, etc., pseudo- nickname of RBv is only used for native frame and TRILL data frame in this specification. 5.1. Data Frames 5.1.1. Native Frames Ingressing When RB1 receives a native frame on one of its valid member ports of RBv, it uses the pseudo-nickname of RBv, instead of its own nickname, as ingress nickname of TRILL header in doing necessary TRILL- encapsulation on the frame if it is uninhibited appointed forwarder for the VLAN of the frame on the port. If the frame is not received on such a port, RB1 MUST NOT use RBv's pseudo-nickname as ingress nickname when encapsulating the frame with a TRILL header. Otherwise, the reverse traffic may be forwarded to another member RBridge that does not connect to the link containing the destination, which may cause the traffic disruption. Zhai, et al. Expires November 16, 2012 [Page 8] Internet-Draft Pseudo-Nickname MAY 2012 If the above native frame is ingressed by RB1 as a multi-destination TRILL data frame, e.g., its destination is unknown to RB1 or it is non-unicast frame, RB1 can only choose one of its assigned distribution trees for RBv to distribute the TRILL-encapsulated frame[cmt]. If not so, the multi-destination TRILL data frame will fail RPF check on another RBridge and be dropped. 5.1.2. TRILL Data Frames Egressing This section describes egress processing of the received TRILL data frames on member RBridges RBn in virtual RBridge group of RBv. Section 5.1.2.1 describes unicast TRILL data frames egress processing. Section 5.1.2.2 covers multi-destination TRILL data fames egress processing. 5.1.2.1. Unicast TRILL Data Frames When receiving a unicast TRILL data frame, RBn checks the egress nickname in the TRILL header of the frame. If the egress nickname is one of RBn's own nicknames, the frame is processed as Section 4.6.2.4 in [RFC6325]. If the egress nickname is the pseudo-nickname of RBv's in which RBn is a valid member RBridge, the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown or reserved or the Inner.MacSA is not unicast. If the learned {Inner.MacSA, Inner.VLAN ID, ingress nickname} triplet is a new one or updated the locally stored one, this triplet is shared among the members RBridges in virtual RBridge group RBv (See Appendix A for more details for the triplet sharing). Then the frame being forwarded is de-capsulated to native form. The Inner.MacDA and Inner.VLAN ID are looked up in RBn's local address cache, and one of the three following cases occurs: o If the destination end station identified by the Inner.MacDA and Inner.VLAN ID is on a local links to RBv, this frame is sent onto the link containing the destination. o else if RBn can reach the destinaiton through another RBridge RBm, it re-encapsulate the native frame into a unicast TRILL data frame and sends it to RBk. RBn uses RBk's own nickname, instead of RBv's pseudo-nickname for the re-encapsulation, and remains the ingress nickname unchanged. o Else, RBn does not know how to reach the destination; it sends the native frame out of all its member ports of RBv. Zhai, et al. Expires November 16, 2012 [Page 9] Internet-Draft Pseudo-Nickname MAY 2012 NOTE: In the first and third case, whether RBn is the appointed forwarder for the frame's VLAN on the link(s) or not, it sends the unicast frame onto the link(s). 5.1.2.2. Multi-Destination TRILL Data Frames If the RBn is an appointed forwarder for the Inner.VLAN ID of the frame, the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown or reserved or the Inner.MacSA is not unicast. If the learned {Inner.MacSA, Inner.VLAN ID, ingress nickname} triplet is a new one or updated the locally stored one, this triplet is shared among the members RBridges in virtual RBridge group RBv (See Appendix A for more details for the triplet sharing). Then a copy of the frame is de-capsulated into its native form. Before the native frame is sent out of ports on which RBn is appointed forwarder for the frame's VLAN, the following extra check is performed: o Assigned Distribution Trees Check (ADT)GBPoIf the flag for this check (ADT_flag) is not zero on such a port, the distribution tree T on which the TRILL data frame arrives at RBn is checked. Only if T is one of RBn's assigned distribution trees in RBv, the native frame can be send out of this port. If not, the frame cannot be sent out of this port. The value of ADT_flag on a RBridge's end-station-servicing port depends on whether the port is a member port of RBv and RBn is the appointed forwarder for all VLANs on this port or not. If so, the ADT_flag on this port MUST be set zero. Otherwise, ADT_flag MUST NOT be set zero. 5.2. OAM Frames For member RBridges, when they originate TRILL OAM frames, they MUST NOT use RBv's pseudo-nickname as ingress nickname in this frame's TRILL header. Otherwise, it is possible that the reverse OAM message is not able to return to the original member RBridge, resulting in the OAM session disruption. 6. IANA Considerations TBD. Zhai, et al. Expires November 16, 2012 [Page 10] Internet-Draft Pseudo-Nickname MAY 2012 7. Security Considerations TBD. 8. Acknowledgements We would like to thank Mingjiang Chen for his contributions to this document. Additionally, we would like to thank Erik Nordmark, Les Ginsberg, Ayan Banerjee, Dinesh Dutt, Anoop Ghanwani, Mingui Zhang, Janardhanan Pathang, Jon Hudson, and Tissa Senevirathne for their good questions and comments. 9. Normative References [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, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [cmt] Senevirathne, T., Pathangi, J., and J. Hudson, "Coordinated Multicast Trees (CMT)for TRILL", draft-ietf-trill-cmt-00.txt Work in Progress, April 2012. [rfc6326bis] Eastlake 3rd, D., Banerjee, A., Ghanwani, A., and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis-rfc6326bis-07.txt Work in Progress, March 2012. Zhai, et al. Expires November 16, 2012 [Page 11] Internet-Draft Pseudo-Nickname MAY 2012 Authors' Addresses Hongjun Zhai ZTE 68 Zijinghua Road, Yuhuatai District Nanjing, Jiangsu 210012 China Phone: +86 25 52877345 Email: zhai.hongjun@zte.com.cn Fangwei Hu ZTE 889 Bibo Road, Pudong District Shanghai, Shanghai 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Radia Perlman Intel Labs 2200 Mission College Blvd Santa Clara, CA 95054-1549 USA Phone: +1-408-765-8080 Email: Radia@alum.mit.edu Donald Eastlake 3rd Huawei 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-333-2270 Email: d3e3e3@gmail.com Zhai, et al. Expires November 16, 2012 [Page 12]