TRILL H. Zhai Internet-Draft F. Hu Intended status: Standards Track ZTE Corporation Expires: January 5, 2012 Radia. Perlman Intel Labs Donald. Eastlake 3rd Huawei technology Jul 4, 2011 RBridge: Pseudonode Nickname draft-hu-trill-pseudonode-nickname-00.txt Abstract 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. If the appointed forwarder for an end station is changed, the remote data traffic to the end station could fail. This document is proposed to assign a nickname for pseudonode identifying a multi-access link to solve the issue. When any appointed forwarder encapsulates a packet, it uses the pseudonode nickname as "ingress nickname" rather than its own nickname. If it does, then if the appointed forwarder changes, or the DRB changes, and the pseudonode still uses the same nickname, then the remote RBridge caches won't need to change, and the data traffic to the end station would reach the link uninterruptedly. 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 January 5, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Zhai, et al. Expires January 5, 2012 [Page 1] Internet-Draft Pseudonode Nickname Jul 2011 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. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Pseudonode Nickname . . . . . . . . . . . . . . . . . . . . . 4 3. LSP Announcement . . . . . . . . . . . . . . . . . . . . . . . 4 4. Unicast TRILL Data Frames Processing . . . . . . . . . . . . . 5 4.1. Ingress processing . . . . . . . . . . . . . . . . . . . . 5 4.2. Egress processing . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Unicasting to VLAN-x Forwarder . . . . . . . . . . . . 6 4.2.2. Multicasting to VLAN-x forwarder . . . . . . . . . . . 6 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . . 7 5. TLV Extensions for Pseudonode Nickname . . . . . . . . . . . . 8 5.1. Pseudonode Nickname Capability in Hellos . . . . . . . . . 8 5.2. Pseudonode Nickname TLV . . . . . . . . . . . . . . . . . 9 5.2.1. Pseudonode Nickname TLV in Hellos . . . . . . . . . . 10 5.2.2. Pseudonode Nickname TLV in DRB's LSPs . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative references . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Zhai, et al. Expires January 5, 2012 [Page 2] Internet-Draft Pseudonode Nickname Jul 2011 1. Problem Statement The IETF TRILL protocol [RFCtrill] provides optimal pair-wise data frame forwarding without configuration, 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] [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. The AF (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. If the appointed forwarder for an end station goes down and a different RBridge is appointed as appointed forwarder on the link, the end station will not perceive the changes.Therefore, the cache in remote RBridge could not be correct until it receives the data traffic from the end station, and the traffic from the remote RBridge to the end station could fail for a while. It is even worse for the Swap Nickname Field approach in multi-level TRILL network, for the egress RBridge of remote level 1 area cannot update the correspondence of MAC/VLAN-x and the pair of {ingress nickname, swap ingress nickname} until it receives the data traffic from end station [MultilevelTrill]. Pseudonode nickname is proposed in this document to solve the above issue. Pseudonode nickname is assigned by DRB and used to identify a multi-access link. With pseudonode nickname, the data traffic to the end station can reach the destination link uninterruptedly and be forwarded to the end station by other RBridge even if the appointed forwarder for the VLAN on the link is changed. The pseudonode nickname is only used in unicast data traffic and not used in multicast data traffic in this document. For the multicast data traffic, the data traffic goes through the distribution tree, and all the RBridge with the same VLAN can receive the multicast traffic. This document is organized as following: Section 2 is the concept of pseudonode nickname. Section 3 introduces the LSP announcement mechanism for the pseudonode nickname. Section 4 describes the ingress, transit and egress RBridge processing of the TRILL data traffic when considering pseudonode nickname. Section 5 specifies pseudonode nickname capability TLV and pseudonode nickname TLV format. Zhai, et al. Expires January 5, 2012 [Page 3] Internet-Draft Pseudonode Nickname Jul 2011 2. Pseudonode Nickname Pseudonode nickname is used to identify a link. It is assigned by DRB on the link. When the RBridge becomes DRB and it doesn't find the pseudonode nickname from TRILL Hello of other RBridges, DRB assigns and announces a pseudonode nickname in its TRILL Hello on the link. If the new DRB obtains the pseudonode nickname from the TRILL Hellos of adjacent RBridges on the link, it reuses this nickname. The nickname for the pseudonode should keep unchanged even if the DRB or AF changed. All the RBridges on the link should support pseudonode nickname, otherwise the RBridges that don't understand pseudonode nickname on the link cannot forward the encapsulated TRILL frame with pseudonode nickname. Each RBridge on the link announces its pseudonode nickname capability in its TRILL Hello. Only if DRB checks that all the adjacencies in Report state support and enable the pseudonode nickname capability, DRB assigns pseudonode nickname on the link. If not, DRB MUST NOT announce the pseudonode nickname in its pseudonode LSP in the TRILL campus network, otherwise, the remote data traffic may be forwarded to the RBridge without pseudonode nickname capability, and be discarded in the RBridge. The bypass pseudonode bit is used to determine whether DRB should generate the pseudonode LSP. When bypass pseudonode bit is reset, the DRB should support pseudonode function and generate the pseudonode LSP [TrillAdj]. So if DRB assigns pseudonode nickname on the link, the bypass pseudonode bit MUST be reset in its TRILL Hello. 3. LSP Announcement Pseudonode nickname is only announced in the DRB's pseudonode LSP in the TRILL Network. If one of the RBridges on the link is disabled of the pseudonode nickname function, that is, DRB receives a TRILL Hello without pseudonode nickname capability from the port on the link, the pseudonode nickname function should be disabled on the link, and then DRB updates its pseudonode LSP which doesn't include pseudonode nickname TLV in the TRILL campus network. While if an RBridge (not DRB) supporting pseudonode nickname joins into or exits from the link , it is no influence to the pseudonode nickname LSP originated by DRB. If an RBridge is selected as new DRB and the pseudonode nickname capability on the link is confirmed, it will generate and flood pseudonode LSP including the pseudonode nickname TLV in the TRILL campus network.If DRB finds that the pseudonode nickname function is disabled on the link, it will updates its pseudonode LSP which doesn't include pseudonode nickname TLV in the TRILL campus network. Zhai, et al. Expires January 5, 2012 [Page 4] Internet-Draft Pseudonode Nickname Jul 2011 The pseudonode nickname is participated in path computing. The procedure of path computing of pseudonode nickname is same as the routing computing of IPv4 or IPv6 address in layer 3 IS-IS network[RFC1195]. 4. Unicast TRILL Data Frames Processing The processing of TRILL data frames on ingress and egress RBridges will be influenced when the pseudonode nickname capability is enabled on the link. However, the processing on transit RBridges remains unchanged. Section 4.1 covers the changes of processing TRILL data frames on a pseudonode nickname participated ingress RBridge. Section 4.2 describes two methods to process TRILL data frames on egress RBridge. 4.1. Ingress processing When a VLAN-x tagged native frame is sent onto a multi-access link, only the appointed forwarder for that VLAN-x can ingress this frame into TRILL campus. If the pseudonode nickname capability is enabled on the link, the forwarder will encapsulate the frame with a TRILL header, where the ingress nickname is the pseudonode nickname rather than RBridge's nickname on the link. The encapsulation of the native frame is as same as Section 4.1 in [RFCtrill] except for the ingress nickname in TRILL header. 4.2. Egress processing On receiving a unicast TRILL data frame, the egress nickname in the TRILL header is examined, and if it is unknown or reserved, the frame is discarded. Then the Inner.VLAN ID, i.e., VLAN-x, is checked. If it is 0x0 or 0xFFF, the frame is discarded. This RBridge will be the egress RBridge for the TRILL data frame, if the egress nickname is one of the RBridge's nicknames or one of the pseudonode nicknames of the connected links. If the egress RBridge is the VLAN-x forwarder on the destination link for this TRILL data frame, the frame is processed and the original self-learning is performed by this RBridge as described in [RFCtrill]. Otherwise, the frame will be re-encapsulated and transmitted on the link by the egress RBridge. Only the VLAN-x forwarder can decapsulate the TRILL data frame to native form and forward it to the end station on the link, which is consistent with the principle of ingressing and egressing native frame into and out of TRILL campus, i.e., there is only a single RBridge on each link that is in charge of ingressing and egressing native frames from and to that link[TrillAdj]. Zhai, et al. Expires January 5, 2012 [Page 5] Internet-Draft Pseudonode Nickname Jul 2011 There are two methods for the egress to transmit the re-encapsulated TRILL data frame to VLAN-x forwarder on the link. In section 4.2.1, the egress unicasts the re-encapsulated TRILL data frame to the VLAN-x forwarder, and in 4.2.2, the egress multicasts the TRILL data frame on the link. 4.2.1. Unicasting to VLAN-x Forwarder To make the final hop, i.e., the egress RBridge (not VLAN-x forwarder), work for a frame addressed to the pseudonode, the forwarding table has to be based on {nickname, VLAN}, instead of {nickname} currently. In the couple of {nickname, VLAN}, nickname is the pseudonode nickname, and VLAN is the VLAN Id of VLAN-x forwarder on this link. If there are several appointed forwarders, each for a VLAN, on this link, several entries exist in the forwarding table, each for a forwarder. In the couple of {nickname, VLAN}, the VLAN will be ignored if the nickname is not a pseudonode nickname on one of local links, and will be set to invalid value(such as 0x0 or 0xFFF). In other words, if the VLAN in an entry is invalid, the nickname is not a pseudonode nickname. If the RBridge is not VLAN-x forwarder on the link, it goes to its forwarding table that says, based on the pseudonode nickname and VLAN-x Id, which of its RBridge neighbors, i.e., VLAN-x forwarder on this link, to forward to. The forwarder is identified by the next hop MAC address in the found entry from the above table, which is one of the unicast MAC addresses on one of its ports connected directly on this link. The TRILL data frame is discarded if no entry is found. Otherwise, the outer frame header of the TRILL data frame is stripped, the TRILL header remains unchanged, and a new outer frame header is prepended before the frame is forwarded to the VLAN-x forwarder on the link. For the forwarded frame, the Outer.MacSA is the MAC address of the transmitting port on the destination link, the Ouer.MacDA is the next hop MAC address in the found entry and the Outer.VLAN is the designated VLAN on the destination link. If the above re-encapsulated TRILL data frame is received by a stale VLAN-x forwarder on the destination link, it will be dropped by the RBridge. Otherwise, the re-encasulated frame is processed as [RFCtrill], and the Inner.MacSA and Inner.VLAN ID are, by default, learned as associated with the ingress nickname unless that nickname is unknown. 4.2.2. Multicasting to VLAN-x forwarder Alternatively, a special multicast MAC address, named "AF RBridges on this link", can be introduced for the final hop to forward such a TRILL data frame. The scope of the above MAC is limited to local Zhai, et al. Expires January 5, 2012 [Page 6] Internet-Draft Pseudonode Nickname Jul 2011 link, just as the MAC for IS-IS hello PDUs. If a TRILL data frame is addressed to this special MAC and transmitted on a link, all the Appointed Forwarder (AF) RBridges on the link will process it to some extent. With "AF RBridges on this link", the forwarding table remains unchanged in form, i.e., still based {nickname}. For an entry, the next hop MAC address will be "AF RBridges on this link", if the nickname is the pseudonode nickname on one of local links. In other words, if the nickname is a pseudonode nickname, the next hop MAC MUST be "AF RBridges on this link". If not VLAN-x forwarder, the final hop RBridge, RBn, looks up its forwarding table, based on the egress nickname in TRILL header of the received frame. The frame will be discarded if no entry is found. Otherwise, RBn will re-encapsulate the frame, i.e., strip the outer frame header, remain the TRILL header unchanged, prepend a new outer frame header before the frame is transmitted onto the link. For the forwarded frame, the Outer.MacSA is one unicast MAC address on the transmitting port connected to the link, the Ouer.MacDA is the next hop MAC address in the found entry and the Outer.VLAN is the designated VLAN on the link. If the egress nickname is pseudonode nickname, the Outer.VLAN is "AF RBridges on this link" and the re- encapsulated TRILL data frame is multicasted onto the link. The TRILL data frame with "AF RBridges on this link" as Ouer.MacDA is discarded by other RBridges, which are not AF RBridges, on the link. Otherwise, the Inner.VLAN ID, i.e., VLAN-x, is checked. If the VLAN ID is not valid or the receiving RBridge, RBi, is not VLAN-x forwarder on this link, the frame is also discarded. Else, the TRILL data frame is decapsulated into native form and forwarded to the destination end station, and the Inner.MacSA and Inner.VLAN ID are also, by default, learned as associated with the ingress nickname unless that nickname is unknown by RBi. 4.2.3. Comparison With the Unicasting method described in Section 4.2.1 above, the re- encapsulated TRILL data frame by the final hop RBridge is only processed by the VLAN-x forwarder on the link, which can reduce the burden of other RBridges as much as possible. But the forwarding table on ingress/egress SHOULD be changed to be based on {nickname, VLAN}, instead of {nickname}, where each AF Rbridge on a local link is identified by the pseudonode nickname and the vlan id of the AF on the link. With Multicasting method described in Section 4.2.1 above, although all the AF RBridges, except for the final hop RBridge, on the link Zhai, et al. Expires January 5, 2012 [Page 7] Internet-Draft Pseudonode Nickname Jul 2011 are required to process, to some extent, the re-encapsulated TRILL data frame, only the VLAN-x forwarder decapsulates the frame to its native form and forwards it to the destination end station. However, the forwarding table can remain the same as current table in form, i.e., only based on {nickname}. 5. TLV Extensions for Pseudonode Nickname 5.1. Pseudonode Nickname Capability in Hellos The Pseudonode nickname capability of an RBridge MUST be included in one subTLV of Port Capability TLV in the RBridge's TRILL Hello PDUs. This capability is included in Special VLANs and Flags (subTLV Type #1) [TrillISIS]. This subTLV MUST appear exactly once in a Port Information TLV in every TRILL Hello PDU. The length of the value is four octets. Pseudonode Nickname capability TLV +-+-+-+-+-+-+-+-+ |Type=VLAN Flags| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +---------------+---------------+ | Port ID | (2 bytes) +-------------------------------+ | Sender Nickname | (2 bytes) +--+--+--+--+-------------------+ |AF|AC|VM|BY| Outer.VLAN | (2 bytes) +--+--+--+--+-------------------+ |TR|PN|R |R | Desig.VLAN | (2 bytes) +--+--+--+--+-------------------+ Figure 1 The PN bit, if one, indicates that the sending RBridge supports and enables the pseudonode nickname capability. If an RBridge does not support or not enable this capability, the PN bit MUST be set zero. Other bits and fields refer to [TrillISIS]. When receiving this subTLV from other RBridges on the link, the DRB can confirm whether all the adjacencies, in Report state [TrillAdj], support and enable this capability. If not, DRB MUST NOT announce pseudonode nickname in its pseudonode LSPs to the TRILL campus, which can avoid the issue that remote traffic is forwarded to a RBridges without pseudonode nickname capability. Zhai, et al. Expires January 5, 2012 [Page 8] Internet-Draft Pseudonode Nickname Jul 2011 5.2. Pseudonode Nickname TLV If the DRB has confirmed that pseudonode nickname capability can be enabled on this link, it will announce the pseudonode nickname to be used on this link in its hello PDUs and in its pseudonode nickname. The pseudonode nickname is carried in Pseudonode Nickname TLV, which is formatted as following: Pseudonode Nickname TLV +-+-+-+-+-+-+-+-+ |Type= PSEU-NICK| (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSEUDONODE NICKNAME RECORDS (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ................... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSEUDONODE NICKNAME RECORDS (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where each pseudonode nickname record is of the form: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname.Pri |SType| Reserved| (2 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nickname | (2 bytes) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 o Type: Pseudonode Nickname Type, TBD (NICKNAME). o Length: 4*N, where N is the number of pseudonode nickname records present. o SType: An 3-bit unsigned integer sub-type for nickname. If this nickname is pseudonode nickname, value of this field is 1. o Nickname.Pri: An 8-bit unsigned integer priority to hold a nickname as specified in Section 3.7.3 of [RFCtrill]. o Nickname: This is an unsigned 16-bit integer as specified in Section 3.7 of [RFCtrill]. Zhai, et al. Expires January 5, 2012 [Page 9] Internet-Draft Pseudonode Nickname Jul 2011 5.2.1. Pseudonode Nickname TLV in Hellos For an RBridge enabled pseudonode nickname capability on this link, it announces one pseudonode nickname TLV in Hellos if it knows nickname for the pseudonode, otherwise, it MUST NOT announce pseudonode nickname in its Hellos. If DRB has confirmed that pseudonode nickname capability is enabled on this link, the Nickname.Pri in the nickname record MUST be 255, otherwise the Nickname.Pri MUST NOT be 255, and SHOULD be 100 by default. For an RBridge that is not DRB, it only processes the pseudonode nickname announced by DRB, and MUST overwrite its own pseudonode nickname with the DRB's pseudonode nickname if the two nicknames are different and the Nickname.Pri of DRB is 255.DRB should process the pseudonode nickname TLV from all the adjacencies in the Report state on the link in order to obtain the pseudonode nickname that was being used on this link. This TLV MUST appear no more than once in a Port Information TLV in every Hello PDU. Only one nickname record can be contained in this TLV, if this subTLV appears in Hello PDUs. 5.2.2. Pseudonode Nickname TLV in DRB's LSPs For a DRB on a link, it MUST originate and flood a pseudonode LSP for this link if the bypass pseudonode bit is reset. All the adjacencies in the Report state on this link are contained in its pseudonode LSP. Furthermore, if a pseudonode nickname capability is enabled on this link, a Pseudonode Nickname TLV MUST be contained in its pseudonode LSP. For a pseudonode LSP, the only one record in this TLV contains the nickname for the pseudonode standing for the link. In this case, the value of Nickname.Pri varies from 1 to 255, which describes the DRB's priority to hold this nickname as specified in [RFCtrill] Section 3.7.3. 6. Security Considerations 7. Acknowledgements 8. References Zhai, et al. Expires January 5, 2012 [Page 10] Internet-Draft Pseudonode Nickname Jul 2011 8.1. Normative references [MultilevelTrill] Perlman, R., Eastlake, D., and A. Ghanwani, "RBridges: Multilevel TRILL", draft-perlman-trill-rbridge-multilevel-02.txt, work in process, April 2011. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for Layer-2 Systems", RFC 6165, April 2011. [RFCtrill] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- trill-rbridge-protocol-16.txt, in RFC Editor's queue, Mar 2010. [TRILLisis] Eastlake, D., Dutt, D., Perlman, R., and A. Ghanwani, "TRILL Use of IS-IS", draft-ietf-isis-trill-05.txt work in process, Feb 2011. [TrillAdj] Eastlake, D., Perlman, R., Ghanwani, A., Dutt, D., and V. Manral, "RBridges: Adjacency", draft-ietf-trill-adj-02.txt, work in process, Feb 2011. [TrillAf] Perlman, R., Eastlake, D., Banerjee, A., and F. Hu, "RBridges: Appointed Forwarders", draft-ietf-trill-rbridge-af-03.txt work in process, May 2011. 8.2. Informative References Zhai, et al. Expires January 5, 2012 [Page 11] Internet-Draft Pseudonode Nickname Jul 2011 Authors' Addresses Hongjun Zhai ZTE Corporation 68 Zijinghua Road Nanjing 200012 China Phone: +86-25-52877345 Email: zhai.hongjun@zte.com.cn Fangwei Hu ZTE Corporation 889 Bibo Road 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 technology 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-634-2066 Email: d3e3e3@gmail.com Zhai, et al. Expires January 5, 2012 [Page 12]