TRILL WG Fangwei Hu Internet-Draft Jacni Qin Intended status: Standards Track ZTE Expires: July 14, 2012 Donald Eastlake Huawei Radia Perlman Intel Labs Jan 11, 2012 TRILL: Traffic Engineering draft-hu-trill-traffic-engineering-00 Abstract This document specifies the control plane procedures to support Traffic Engineering (TE) in the TRILL protocol. Traffic Engineering permits management configuration of the path followed by certain unicast frames in a TRILL campus. 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 July 14, 2012. Copyright Notice Copyright (c) 2012 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 Hu, et al. Expires July 14, 2012 [Page 1] Internet-Draft TRILL TE Jan 2012 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. Comparison of TE with Multi-Topology . . . . . . . . . . . 3 1.2. Comparison with Layer 3 IS-IS Traffic Engineering . . . . . 3 1.3. Requirements Language . . . . . . . . . . . . . . . . . . . 4 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3. TRILL TE Nickname Allocation . . . . . . . . . . . . . . . . . 4 4. Uses of Traffic Engineering . . . . . . . . . . . . . . . . . . 4 4.1. Protection . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Special Link Characteristics . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Hu, et al. Expires July 14, 2012 [Page 2] Internet-Draft TRILL TE Jan 2012 1. Introduction The IETF TRILL (Transparent Interconnection of Lots of Links) protocol implemented by devices called RBridges (Routing Bridges, [RFC6325]), 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. TE(Traffic Engineering) in a flexible technique that can enhance the performance of an operational network at both the traffic and resource. To support TE in IP networks, extensions to IS-IS [RFC5305], have been specified. Similarly, for TE in TRILL networks, this document describes the control plane procedures and necessary extensions to IS-IS in the context of TRILL protocol. 1.1. Comparison of TE with Multi-Topology Multi-topology [I-D.eastlake-trill-rbridge-multi-topo] affects all frames, multi-destination as well as known unicast. It constrains frames being routed by a particular topology to certain links and, in general, different costs can be provided for the same link as used in different topologies. The number of available topologies is typically limited due to the multiplicative effect of the number of topologies on the routing computation effort. Traffic Engineering applies only to unicast frames as indicated by the use of a TE egress nickname in TRILL network. The forwarding for such frames at each RBridge along the traffic-engineered path can be statically configured or computed based on TE routing metric. However, in both cases, the topology or TE status of a frame can be determined from the egress nickname in the TRILL Header. 1.2. Comparison with Layer 3 IS-IS Traffic Engineering Layer 3 IS-IS Traffic Engineering uses Router ID TLV(TLV 134) [RFC5305] which is typically extracted from the IP address of a loopback interface, to identify the endpoints of tunnels for Traffic Engineering paths. While for TRILL Traffic Engineering, there are no complicated signal protocols and explicitly tunnels signaled, so some "TE Router ID TLV for TRILL" is not required. Hu, et al. Expires July 14, 2012 [Page 3] Internet-Draft TRILL TE Jan 2012 1.3. Requirements Language 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 [RFC2119]. 2. Solution Overview Instead of using explicitly signaled "tunnels" (e.g., MPLS LSP- tunnels for TE), which will require dedicated signaling protocols (e.g., RSVP-TE or CR-LDP) and additional encapsulation in forwarding procedures, nicknames allocated for TE routing path are specially marked in the LSP of the RBridge holding the nickname. The TE path may be calculated based on the TE metrics carried by sub-TLVs inside the existing Extended IS Reachability TLV (TLV type 22, defined in [RFC5305] ) or may be statically configured. Ultimately, a shared forwarding table is generated to maintain forwarding information for the basic routing path and forwarding information for the TE routing path. Other procedures of TRILL protocol for routing and encapsulation are not changed. How to determine whether a frame should be forwarded along least cost routing path or along a particular TE egress nickname routing path is out of the scope of this document. 3. TRILL TE Nickname Allocation A dedicated space of nickname, named TE nickname MUST be allocated for TE path calculation. TE nickname allocation and selection procedures MUST follow what have been specified in [RFC6325]. The TE nickname should be marked in the link state database for TE routing path calculation. The RBridges with TE function enabled should acquire both nicknames and TE nicknames. This document uses Interested VLANs and Roots sub-TLV ([RFC6325]) to specify TE nickname. The VID value 0xFFF reserved in [IEEE802.1Q-2005], is redefined to mark the TE nicknames. 4. Uses of Traffic Engineering Traffic Engineering is a flexible facility with a variety of uses. The following sections introduce two use cases. Hu, et al. Expires July 14, 2012 [Page 4] Internet-Draft TRILL TE Jan 2012 4.1. Protection Reliability is one important purpose of TE deployment. TE path can be used for link or node protection. When nodes or links on basic path fail, frame traffic can switch to TE routing path. See the following example: +-----+ +-----+ basic +-----+ +-----+ | RB1 |--+---| RB2 |-----------| RB3 |---+--| RB4 | +-----+ | +-----+ +-----+ | +-----+ | | | +-----+ TE +-----+ | +---| RB5 |-----------| RB6 |---+ +-----+ +-----+ RB1->RB2->RB3->RB4 is the primary routing path, and the nicknames of RB1, RB2, RB3 and RB4 are N1, N2, N3 and N4. The TE routing path is RB1-> RB5->RB6->RB4, and the TE nicknames of RB1, RB5, RB6 and RB4 are Nte1, Nte5, Nte6 and Nte4. If for example, RB2, or RB3, or the link between RB2 and RB3 fails, when RB1 detects the failure, it switches the frame traffic to the TE routes by encapsulating the TRILL frame with Nte4 as the egress nickname instead of N4. The frame traffic will then be forwarded based on the routing information for the TE path. When the basic route path is recovered or a new basic path is set up, the traffic should be able to switched back over the basic route path. While the switchover function should be configurable and deployment specific. 4.2. Special Link Characteristics TE can be used to send frames over paths so that the links in the path have selected special characteristics. For example, assume MTU testing ([RFC6325])is performed and the results reported in Extended IS-IS Reachability sub-TLVs as described in ([RFC6326bis])and some links in a campus can handle jumbo frames while others can only handle a little over the classic Ethernet maximum. TE could then be used to engineer paths that were limited to links that could handle jumbo frames. 5. Security Considerations For general TRILL Security Considerations, see([RFC6325]). Hu, et al. Expires July 14, 2012 [Page 5] Internet-Draft TRILL TE Jan 2012 6. Acknowledgements TBD 7. IANA Considerations IANA is requested to allocate capability bit TBD in the TRILL-VER sub-TLV capability bits ([RFC6326bis]) to indicate an RBridge has TE implemented and enabled. 8. References 8.1. Normative References [IEEE802.1Q-2005] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks, 802.1Q-2005", May 2006. [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. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, July 2011. [RFC6326bis] Eastlake, D., Banerjee, A., Dutt, D., Ghanwani, A., and R. Perlman, "Transparent Interconnection of Lots of Links (TRILL) Use of IS-IS", draft-eastlake-isis-rfc6326bis-01.txt, work in process, Oct 2011. 8.2. Informative References [I-D.eastlake-trill-rbridge-multi-topo] Eastlake, D., Zhang, M., Perlman, R., Banerjee, A., and V. Manral, "RBridges: Multiple Topology TRILL", draft-eastlake-trill-rbridge-multi-topo-01 (work in progress), July 2011. Hu, et al. Expires July 14, 2012 [Page 6] Internet-Draft TRILL TE Jan 2012 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999. [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002. Authors' Addresses Fangwei Hu ZTE No.889 Bibo Rd Shanghai, 201203 China Phone: +86 21 68896273 Email: hu.fangwei@zte.com.cn Jacni Qin ZTE No.889 Bibo Rd Shanghai, 201203 China Phone: +86 1391 8619 913 Email: jacni@jacni.com Donald Eastlake Huawei 155 Beaver Street Milford, MA 01757 USA Phone: +1-508-634-2066 Email: d3e3e3@gmail.com Hu, et al. Expires July 14, 2012 [Page 7] Internet-Draft TRILL TE Jan 2012 Radia Perlman Intel Labs 2200 Mission College Blvd. Santa Clara, CA 95054-1549 USA Phone: +1-408-765-8080 Email: Radia@alum.mit.edu Hu, et al. Expires July 14, 2012 [Page 8]