TRILL Working Group S.Gai Internet Draft Nuova Systems R. Perlman Sun Microsystems Dinesh G. Dutt Cisco Systems Ed Bowen IBM Expires: April 2007 October 10, 2006 An encapsulation for TRILL draft-gai-perlman-trill-encap-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 10, 2007. Abstract A new layer of encapsulation is required with RBridges. A previous Internet Draft [2] (draft-bryant-perlman-trill-pwe-encap-00) proposes an encapsulation header that contains a Nickname, a flag, TTL and CoS. This document introduces additional fields, and gives arguments for their usefulness. As a result the encapsulation header needs to be expanded and will no longer be able to be in MPLS format. The WG Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 1] Internet-Draft An encapsulation for TRILL October 2006 will need to decide on the tradeoffs between this additional functionality, and compatibility with an existing (MPLS) format. Conventions used in this document 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 RFC-2119 [1]. Table of Contents 1. Introduction...................................................2 2. Encapsulation Format...........................................3 2.1. Encapsulation format over Ethernet........................4 3. FTag...........................................................4 4. Hop Limit......................................................6 5. RBridge addresses..............................................6 5.1. Egress RBridge Address....................................8 5.2. Ingress RBridge Address...................................8 6. Local Identifier (LID).........................................8 6.1. Egress RBridge LID........................................8 6.2. Ingress RBridge LID.......................................9 7. Other considerations related to Ethernet Encapsulation.........9 8. Security Considerations........................................9 9. IANA Considerations...........................................10 10. References...................................................10 10.1. Normative References....................................10 10.2. Informative References..................................10 Author's Addresses...............................................11 Intellectual Property Statement..................................11 Disclaimer of Validity...........................................12 Copyright Statement..............................................12 Acknowledgment...................................................12 1. Introduction Previous work [2], [3] has clearly identified that TRILL encapsulation requires a TTL, an RBridge ID, and a flag to indicate if the frame is unicast or multicast. There has been a proposal to also add a CoS field, but the consensus seems less strong. This proposal expands the scope of the encapsulation to: Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 2] Internet-Draft An encapsulation for TRILL October 2006 o Allow both the ingress and egress RBridge ID to be carried in the frame; o Support multiple forwarding topologies over the same TRILL network by adding an FTag (Forwarding Tag); o Support a simplified RBridge lookup architecture by adding a LID (Local Identifier). 2. Encapsulation Format The proposed encapsulation format is agnostic to the data link layer used and it is depicted in Figure 1. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FTag | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Address | Ingress RBridge LID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Address | Egress RBridge LID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 TRILL Encapsulation o FTag (Forwarding tag): 10-bit selector. See Section 3. o Hop Limit: 6-bit unsigned integer. See Section 4. o Ingress RBridge Address: 16-bit address. See Section 5.2 o Egress RBridge Address: 16-bit address. See Section 5.1 o Ingress RBridge LID: 16-bit address. See Section 6.2 o Egress RBridge LID: 16-bit address. See Section 6.1 Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 3] Internet-Draft An encapsulation for TRILL October 2006 2.1. Encapsulation format over Ethernet The most common encapsulation for TRILL will be the Ethernet encapsulation shown in Figure 2. This encapsulation has the advantage of aligning the original Ethernet frame at 64 bit boundaries. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination MAC Address | Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = TRILL | FTag | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Address | Ingress RBridge LID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Address | Egress RBridge LID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Ethernet frame without FCS | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 TRILL Encapsulation over Ethernet The frame has a single FCS that is recomputed to cover the entire frame. This has become standard practice in IEEE 802.1: the tagging structure effectively requires FCS recomputation at the boundaries of the network. Additionally, the IETF (with diffserv, ECN, routing) have also effectively required FCS recomputation at all boundaries of the network. 3. FTag 10-bit unsigned integer. The Forwarding Tag (FTag) identifies the forwarding topology assigned to a given frame. In current enterprise networks, for a given frame it is possible to pick from multiple topologies on which the frame can be forwarded. More specifically, in existing Ethernet bridges: Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 4] Internet-Draft An encapsulation for TRILL October 2006 o For unicast, it is possible to range from the solution where all the VLANs share the same spanning tree (default 802.1D behavior), to individual spanning tree per VLAN (per-VLAN spanning tree), to spanning trees shared by a set of VLANs (Multiple Spanning Tree). o For multicast, it is possible to have a single tree, or one tree sourced in each bridge, or a set of N shared trees. To provide similar functionality for TRILL an FTag is assigned to each frame by the ingress RBridge and it is honored by all subsequent RBridges within that TRILL cloud. These different forwarding topologies are characterized by different metrics. The link state protocol must carry for each link metrics specified in term of pairs {FTag, value}. FTag allows forwarding based on more than just destination address. For example, FTag assignment may be based on criteria such as protocol, VLAN, or ingress interface. The alternative of not carrying an explicit FTag in the frame, but assign it Hop-by-Hop, is not recommended, since it can easily cause loops and prevent frames from being delivered correctly, especially in the case of multicast, when misconfigured. There are two possible approaches to building multicast trees, as stated earlier: o Source-Rbridge based multicast trees: in this case, a multicast tree is built per Rbridge. The distribution tree used by a multicast group is the first-hop Rbridge's tree. The main advantage of this proposal is optimal forwarding. However, if sources are concentrated behind a few Rbridges, not all links are effectively utilized. Further, all multicast groups, independently of the VLAN, use the same tree. This same tree is used for broadcast originating from behind a Rbridge as well. o Shared Trees: in this case, one or more multicast trees are constructed, one for each of a few well-located Rbridges. The distribution tree used by a {multicast source, multicast group} is determined by hashing the tuple {multicast source, multicast group}. This has the advantage of effectively using all links of the network. One of these trees can be chosen per VLAN as the broadcast tree. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 5] Internet-Draft An encapsulation for TRILL October 2006 Thus, if there are N unicast forwarding topologies (i.e. metrics), M Rbridges and, P multicast trees where P <= M, (N+P) <= 1024 and 1 <= N <= (1024-P). One value of FTag (probably zero) should be reserved to be the default (single topology) and all links must have a metric implicitly or explicitly assigned for that FTag value. 4. Hop Limit 6-bit unsigned integer. This is decremented by 1 at each node that forwards the frame. The frame is discarded if Hop Limit is decremented to zero. This field was previously referred to as TTL (Time To Live). In IPv6 the IETF has replaced the concept of TTL with Hop Limit. TRILL aligns with this newer definition. 5. RBridge addresses 16-bit address. This is also referred to as "RBridge nickname". It is not the MAC address of the Rbridge, it is the TRILL address of the RBridge. The current TRILL proposal has a single field that sometimes contains the ingress, and sometimes the egress RBridge address, indicated by a flag in the 20-bit field. Unicast packets indicate egress RBridge, and non-unicast indicates ingress RBridge. This may be confusing and, in protocol design it is common practice to have both the ingress and egress addresses. This is particularly true when security is taken into account. In particular, in the case of unicast, if only the egress RBridge is in the header, there is no information about where the packet entered the backbone (the ingress RBridge). This information might be useful for policy/filtering decisions. Also, if in the future we want to allow learning of endnode locations based on seeing data frames, it is useful to have the ingress RBridge address in the header, so that RBridges can learn the tuple {ingress RBridge address, ingress RBridge LID, endnode}. In the case of multicast/broadcast, currently only the ingress RBridge is in the header. The egress RBridge address can be used to encode information so that the RBridges does not need to look inside the header to find out, for instance, what the VLAN tag is. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 6] Internet-Draft An encapsulation for TRILL October 2006 This document proposes instead two 16-bit fields, one for ingress, and one for egress. The following types of packets need to be considered: o unicast (where the egress RBridge is known) o unicast flooding (where the destination is unknown so the packet must be flooded to all egress RBridges) o Registered multicast (where receivers have registered, through IGMP or GARP) o Non-registered multicast (where receivers have not registered, and so data must be delivered to all links in the VLAN). o VLAN broadcast The most significant bits of the address have the meaning specified in Figure 3. +------------------+------------ | 0xxxxxxxxxxxxxxx | Unicast +------------------+------------ | 100ryyyyyyyyyyyy | Unicast Flooding +------------------+------------ | 101ryyyyyyyyyyyy | Registered Multicast +------------------+------------ | 110ryyyyyyyyyyyy | Non-Registered Multicast +------------------+------------ | 111ryyyyyyyyyyyy | VLAN Broadcast +------------------+------------ Figure 3 Format of RBridge addresses Where: o xxxxxxxxxxxxxxx is the 15 bit identifier of an RBridge o r is 1 bit reserved field o yyyyyyyyyyyy is a 12 bit VLAN identifier. The VLAN identifier is taken by the 802.1Q tag if present and different from zero, or by the Interface VLAN parameter in the other cases. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 7] Internet-Draft An encapsulation for TRILL October 2006 This assignment allows addressing up to 32K RBridges. 5.1. Egress RBridge Address The egress RBridge address may assume all formats listed in Figure 3. In particular: o For known-unicast it assumes the unicast format where xxxxxxxxxxxxxxx contains the identifier of the egress RBridge. o For unknown-unicast, registered multicast, non-registered multicast, and broadcast, yyyyyyyyyyyy is the VLAN identifier. 5.2. Ingress RBridge Address The ingress RBridge address may assume only the unicast format (see Figure 3). xxxxxxxxxxxxxxx contains the identifier of the ingress RBridge. 6. Local Identifier (LID) This 16-bit number is of significance to the ingress/egress RBridge inserting/removing the encapsulation. The most common use is as a hint to the egress Rbridge of the output interface. The LIDs are ignored by intervening RBridges. The implication on the design is to change slightly how endnodes are reported in the endnode report LSP (the per-VLAN instance which reports attached endnodes). Each RBridge must report the tuple {MAC- address, RBridge Address, LID} for each MAC address. This does not add computational overhead in the RBridge, since the LIDs are not part of the topology. 6.1. Egress RBridge LID The egress LID simplifies significantly the forwarding decision of the egress RBridge. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 8] Internet-Draft An encapsulation for TRILL October 2006 The ingress RBridge looks up the endnode MAC address, identify an adjacency table entry that contains the pair {egress RBridge address, egress RBridge LID) and insert them in the TRILL header. Each RBridge looks at the Egress RBridge address to decide if it is the egress RBridge. The egress RBridge remove the encapsulation and can send the frame out to the correct interface, by using the LID from the packet, without requiring additional lookups of the inner MAC address. 6.2. Ingress RBridge LID This is to provide the capability to learn the information (ingress RBridge, LID) from data packets, rather than reporting this information in link state reports. 7. Other considerations related to Ethernet Encapsulation The current TRILL architecture assumes all links are shared-media Ethernet. The outer header is really link-specific, and although the document specifies only shared-media Ethernet links, it ought to be clear that other links are allowed. In particular, if there is a direct RBridge-to-RBridge point-to-point link, there is no need for the outer header. However, if the link is Ethernet point-to-point sending an Ethernet frame without MAC addresses is probably not a good idea, it is better to set them to a predefined value in transmission and ignore them in reception. 8. Security Considerations No matter what the format of the encapsulation header is, an RBridge can modify the value in the encapsulation header, and cause packet misrouting. This format should not change the security implications of RBridges. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 9] Internet-Draft An encapsulation for TRILL October 2006 9. IANA Considerations This format requires a new Ethertype in the outer header, to indicate this encapsulation format. Even with the MPLS format, an Ethertype needed to be assigned to RBridges, so this does not require additional values to be assigned. 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [2] S. Bryant, R. Perlman, A. Atlas, D. Fedyk, "TRILL using Pseudo- Wire Emulation (PWE) Encapsulation", draft-bryant-perlman- trill-pwe-encap-00, October 16, 2005 [3] R. Perlman, J. Touch, "RBridges: Base Protocol Specification," draft-ietf-trill-RBridge-protocol-00.txt, May 10, 2006 Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 10] Internet-Draft An encapsulation for TRILL October 2006 Author's Addresses Silvano Gai Nuova Systems Email: sgai@nuovasystems.com Radia Perlman Sun Microsystems Email: Radia.Perlman@sun.com Dinesh G. Dutt Cisco Systems Email: ddutt@cisco.com Ed Bowen IBM Email: edbowen@us.ibm.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 11] Internet-Draft An encapsulation for TRILL October 2006 Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gai,Perlman,Dutt,Bowen Expires April 10, 2007 [Page 12]