Internet DRAFT - draft-hu-trill-traffic-engineering

draft-hu-trill-traffic-engineering






TRILL WG                                                     Fangwei. Hu
Internet-Draft                                                       ZTE
Intended status: Standards Track                              Jacni. Qin
Expires: January 6, 2013                                           Cisco
                                                    Donald. Eastlake 3rd
                                                       Huawei technology
                                                          Radia. Perlman
                                                              Intel Labs
                                                            July 5, 2012


                       Trill Traffic Engineering
                 draft-hu-trill-traffic-engineering-01

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 January 6, 2013.

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



Hu, et al.               Expires January 6, 2013                [Page 1]

Internet-Draft                  TRILL TE                       July 2012


   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.  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 January 6, 2013                [Page 2]

Internet-Draft                  TRILL TE                       July 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 January 6, 2013                [Page 3]

Internet-Draft                  TRILL TE                       July 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.

   Another solution is to use the T flag in the nicknanme Flag Sub-TLV
   defined in ([RFC6326bis]) to indicats that the nickname is used for
   traffic engineering routing.


4.  Uses of Traffic Engineering

   Traffic Engineering is a flexible facility with a variety of uses.



Hu, et al.               Expires January 6, 2013                [Page 4]

Internet-Draft                  TRILL TE                       July 2012


4.1.  Protection

   Reliability is one important purpose of TE deployment.  TE path can
   be calculated as the backup path for the basic path, and used for
   link or node protection of the basic path.  The TE path is identified
   and formed by TE nickname.  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 January 6, 2013                [Page 5]

Internet-Draft                  TRILL TE                       July 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, "Multiple Topology TRILL",
              draft-eastlake-trill-rbridge-multi-topo-02 (work in
              progress), January 2012.



Hu, et al.               Expires January 6, 2013                [Page 6]

Internet-Draft                  TRILL TE                       July 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
   Cisco
   Shanghai,
   China

   Phone: +86 1391 8619 913
   Email: jacni@jacni.com


   Donald Eastlake,3rd
   Huawei technology
   155 Beaver Street
   Milford, MA 01757
   USA

   Phone: +1-508-634-2066
   Email: d3e3e3@gmail.com













Hu, et al.               Expires January 6, 2013                [Page 7]

Internet-Draft                  TRILL TE                       July 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 January 6, 2013                [Page 8]