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]
