IS-IS Extensions for Traffic Engineering
RFC 5305
Document | Type |
RFC - Proposed Standard
(October 2008; No errata)
Obsoletes RFC 3784
|
|
---|---|---|---|
Authors | Tony Li , Henk Smit | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5305 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ross Callon | ||
Send notices to | tony.li@tony.li |
Network Working Group T. Li Request for Comments: 5305 Redback Networks, Inc. Obsoletes: 3784 H. Smit Category: Standards Track October 2008 IS-IS Extensions for Traffic Engineering Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. Li & Smit Standards Track [Page 1] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008 Table of Contents 1. Introduction ....................................................2 1.1. Requirements Language ......................................3 2. Introducing Sub-TLVs ............................................3 3. The Extended IS Reachability TLV ................................3 3.1. Sub-TLV 3: Administrative Group (color, resource class) ....6 3.2. Sub-TLV 6: IPv4 Interface Address ..........................6 3.3. Sub-TLV 8: IPv4 Neighbor Address ...........................6 3.4. Sub-TLV 9: Maximum Link Bandwidth ..........................7 3.5. Sub-TLV 10: Maximum Reservable Link Bandwidth ..............7 3.6. Sub-TLV 11: Unreserved Bandwidth ...........................7 3.7. Sub-TLV 18: Traffic Engineering Default Metric .............8 4. The Extended IP Reachability TLV ................................8 4.1. The up/down Bit ...........................................10 4.2. Expandability of the Extended IP Reachability TLV with Sub-TLVs .............................................11 4.3. The Traffic Engineering Router ID TLV .....................11 5. IANA Considerations ............................................12 5.1. TLV Codepoint Allocations .................................12 5.2. New Registries ............................................13 5.2.1. Sub-TLVs for the Extended IS Reachability TLV ......13 5.2.2. Sub-TLVs for the Extended IP Reachability TLV ......15 6. Security Considerations ........................................15 7. Acknowledgements ...............................................15 8. References .....................................................15 8.1. Normative References ......................................15 8.2. Informative References ....................................15 1. Introduction The IS-IS protocol is specified in ISO 10589 [ISO-10589], with extensions for supporting IPv4 specified in [RFC1195]. Each Intermediate System (IS) (router) advertises one or more IS-IS Link State Protocol Data Units (LSPs) with routing information. Each LSP is composed of a fixed header and a number of tuples, each consisting of a Type, a Length, and a Value. Such tuples are commonly known as TLVs, and are a good way of encoding information in a flexible and extensible format. This document contains the design of new TLVs to replace the existing IS Neighbor TLV and IP Reachability TLV, and to include additional information about the characteristics of a particular link to an IS- IS LSP. The characteristics described in this document are needed for traffic engineering [RFC2702]. Secondary goals include increasing the dynamic range of the IS-IS metric and improving the encoding of IP prefixes. Li & Smit Standards Track [Page 2] RFC 5305 IS-IS Extensions for Traffic Engineering October 2008 The router ID is useful for traffic engineering purposes because it describes a single address that can always be used to reference a particular router. Mechanisms and procedures to migrate to the new TLVs are not discussed in this document. A prior version of this document was published as [RFC3784] with Informational status. This version is on the standards track. 1.1. 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].Show full document text