| < draft-ietf-isis-traffic-04.txt | draft-ietf-isis-traffic-05.txt > | |||
|---|---|---|---|---|
| Network Working Group Henk Smit | Network Working Group Henk Smit | |||
| INTERNET DRAFT Tony Li | INTERNET DRAFT Tony Li | |||
| Procket Networks | Procket Networks | |||
| December 2002 | August 2003 | |||
| IS-IS extensions for Traffic Engineering | IS-IS extensions for Traffic Engineering | |||
| <draft-ietf-isis-traffic-04.txt> | <draft-ietf-isis-traffic-05.txt> | |||
| Status | Status | |||
| This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is subject to all provisions | |||
| all provisions of Section 10 of RFC 2026 except that the right to | of Section 10 of RFC2026. | |||
| produce derivative works is not granted. | ||||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet- Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| 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. | ||||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| Abstract | Abstract | |||
| This document describes extensions to the IS-IS protocol to support | This document describes extensions to the IS-IS protocol to support | |||
| Traffic Engineering. | Traffic Engineering. | |||
| skipping to change at line 72 ¶ | skipping to change at page 2, line 30 ¶ | |||
| The primary goal of these extensions is to add more information about | The primary goal of these extensions is to add more information about | |||
| the characteristics of a particular link to an IS-IS's LSP. The | the characteristics of a particular link to an IS-IS's LSP. The | |||
| characteristics described in this document are needed for Traffic | characteristics described in this document are needed for Traffic | |||
| Engineering [4] (TE). Secondary goals include increasing the dynamic | Engineering [4] (TE). Secondary goals include increasing the dynamic | |||
| range of the IS-IS metric and improving the encoding of IP prefixes. | range of the IS-IS metric and improving the encoding of IP prefixes. | |||
| The router id is useful for traffic engineering purposes because it | The router id is useful for traffic engineering purposes because it | |||
| describes a single address that can always be used to reference a | describes a single address that can always be used to reference a | |||
| particular router. | particular router. | |||
| This document is a publication of the IS-IS Working Group within the | ||||
| IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual | ||||
| inclusion with ISO 10589 [1]. | ||||
| 2.0 Introducing Sub-TLVs | 2.0 Introducing Sub-TLVs | |||
| This document introduces a new way to encode routing information in | This document introduces a new way to encode routing information in | |||
| IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to | IS-IS. The new object is called a sub-TLV. Sub-TLVs are similar to | |||
| regular TLVs. They use the same concepts as regular TLVs. The | regular TLVs. They use the same concepts as regular TLVs. The | |||
| difference is that TLVs exist inside IS-IS packets, while sub-TLVs | difference is that TLVs exist inside IS-IS packets, while sub-TLVs | |||
| exist inside TLVs. TLVs are used to add extra information to IS-IS | exist inside TLVs. TLVs are used to add extra information to IS-IS | |||
| packets. Sub-TLVs are used to add extra information to particular | packets. Sub-TLVs are used to add extra information to particular | |||
| TLVs. Each sub-TLV consists of three fields. A one-octet Type field, | TLVs. Each sub-TLV consists of three fields. A one-octet Type field, | |||
| a one-octet Length field, and zero or more octets of Value. The Type | a one-octet Length field, and zero or more octets of Value. The Type | |||
| skipping to change at line 350 ¶ | skipping to change at page 8, line 25 ¶ | |||
| 0 0 | 0 0 | |||
| 1-8 1 | 1-8 1 | |||
| 9-16 2 | 9-16 2 | |||
| 17-24 3 | 17-24 3 | |||
| 25-32 4 | 25-32 4 | |||
| The remaining bits of prefix are transmitted as zero and ignored upon | The remaining bits of prefix are transmitted as zero and ignored upon | |||
| receipt. | receipt. | |||
| If a prefix is advertised with a metric larger then MAX_PATH_METRIC | If a prefix is advertised with a metric larger then MAX_PATH_METRIC | |||
| (0xFE000000, see paragraph 4.0), this prefix MUST NOT be considered | (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered | |||
| during the normal SPF computation. This allows advertisement of a | during the normal SPF computation. This allows advertisement of a | |||
| prefix for other purposes than building the normal IP routing table. | prefix for other purposes than building the normal IP routing table. | |||
| 4.1 The up/down bit | 4.1 The up/down bit | |||
| Without any additional mechanisms, if routers were allowed to | Without any additional mechanisms, if routers were allowed to | |||
| redistribute IP prefixes freely in both directions between level 1 | redistribute IP prefixes freely in both directions between level 1 | |||
| and level 2, those routers can not determine looping of routing | and level 2, those routers can not determine looping of routing | |||
| information. A problem occurs when a router learns a prefix via | information. A problem occurs when a router learns a prefix via | |||
| level 2 routing and advertises that prefix down into a level 1 area, | level 2 routing and advertises that prefix down into a level 1 area, | |||
| skipping to change at line 440 ¶ | skipping to change at page 10, line 23 ¶ | |||
| If a router advertises the Traffic Engineering router ID TLV in its | If a router advertises the Traffic Engineering router ID TLV in its | |||
| LSP, and if it advertises prefixes via the Border Gateway Protocol | LSP, and if it advertises prefixes via the Border Gateway Protocol | |||
| (BGP) with the BGP next hop attribute set to the BGP router ID, in | (BGP) with the BGP next hop attribute set to the BGP router ID, in | |||
| that case the Traffic Engineering router ID SHOULD be the same as the | that case the Traffic Engineering router ID SHOULD be the same as the | |||
| BGP router ID. | BGP router ID. | |||
| Implementations MUST NOT inject a /32 prefix for the router ID into | Implementations MUST NOT inject a /32 prefix for the router ID into | |||
| their forwarding table, because this can lead to forwarding loops | their forwarding table, because this can lead to forwarding loops | |||
| when interacting with systems that do not support this TLV. | when interacting with systems that do not support this TLV. | |||
| 6. IANA Considerations | ||||
| 6.1 TLV codepoint allocations | ||||
| This document defines the following new ISIS TLV types that need to | ||||
| be reflected in the ISIS TLV code-point registry: | ||||
| Type Description IIH LSP SNP | ||||
| ---- ----------------------------------- --- --- --- | ||||
| 22 The extended IS reachability TLV n y n | ||||
| 134 The Traffic Engineering router ID TLV n y n | ||||
| 135 The extended IP reachability TLV n y n | ||||
| 6.2 New registries | ||||
| IANA is requested to create the following new registries. | ||||
| 6.2.1 Sub-TLVs for TLV 22 | ||||
| This registry contains codepoints for Sub-TLVs of TLV 22. The range | ||||
| of values is 0-255. Allocations within the registry require | ||||
| documentation of the use of the allocated value and approval by the | ||||
| Designated Expert assigned by the IESG (see [5]). | ||||
| Taking into consideration allocations specified in this document, the | ||||
| registry should be initialized as follows: | ||||
| Type Description | ||||
| ---- ----------------------------------- | ||||
| 0-2 unassigned | ||||
| 3 Administrative group (color) | ||||
| 4-5 unassiged | ||||
| 6 IPv4 interface address | ||||
| 7 unassigned | ||||
| 8 IPv4 neighbor address | ||||
| 9 Maximum link bandwidth | ||||
| 10 Reservable link bandwidth | ||||
| 11 Unreserved bandwidth | ||||
| 12-17 unassigned | ||||
| 18 TE Default metric | ||||
| 19-254 unassigned | ||||
| 255 Reserved for future expansion | ||||
| <IANA-note> To be removed by the RFC editor at the time of publication | ||||
| At the time of registry creation, please perform the following | ||||
| allocations in this registry: | ||||
| Type Description | ||||
| ---- ----------------------------------- | ||||
| 250 Reserved for Cisco-proprietary extensions | ||||
| 251 Reserved for Cisco-proprietary extensions | ||||
| </IANA-note> | ||||
| 6.2.2 Sub-TLVs for TLV 135 | ||||
| This registry contains codepoints for Sub-TLVs of TLV 135. The range | ||||
| of values is 0-255. Allocations within the registry require | ||||
| documentation of the use of the allocated value and approval by the | ||||
| Designated Expert assigned by the IESG (see [5]). | ||||
| No codepoints are defined in this document. | ||||
| Normative References | Normative References | |||
| [1] ISO 10589, "Intermediate System to Intermediate System Intra- | [1] ISO, "Intermediate System to Intermediate System Intra-Domain | |||
| Domain Routeing Exchange Protocol for use in Conjunction with the | Routeing Exchange Protocol for use in Conjunction with the Protocol | |||
| Protocol for Providing the Connectionless-mode Network Service (ISO | for Providing the Connectionless-mode Network Service (ISO 8473)", | |||
| 8473)" [Also republished as RFC 1142] | International Standard 10589:2002, Second Edition | |||
| [2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS", | [2] RFC 2966, "Domain-wide Prefix Distribution with Two-Level IS-IS", | |||
| T. Li, T. Przygienda, H. Smit, October 2000. | T. Li, T. Przygienda, H. Smit, October 2000. | |||
| Informative References | Informative References | |||
| [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual | [3] RFC 1195, "Use of OSI IS-IS for routing in TCP/IP and dual | |||
| environments", R.W. Callon, December 1990 | environments", R.W. Callon, December 1990 | |||
| [4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. | [4] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D. | |||
| Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September | Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September | |||
| 1999. | 1999 | |||
| [5] RFC 2434, "Guidelines for Writing an IANA Considerations Section | ||||
| in RFCs", Narten, T., and H. Alvestrand, BCP 26, October 1998 | ||||
| Security Considerations | Security Considerations | |||
| This document raises no new security issues for IS-IS. | This document raises no new security issues for IS-IS. | |||
| Acknowledgments | Acknowledgments | |||
| The authors would like to thank Yakov Rekhter and Dave Katz for their | The authors would like to thank Yakov Rekhter and Dave Katz for their | |||
| comments on this work. | comments on this work. | |||
| skipping to change at line 479 ¶ | skipping to change at page 12, line 40 ¶ | |||
| Tony Li | Tony Li | |||
| Procket Networks, Inc. | Procket Networks, Inc. | |||
| 1100 Cadillac Court | 1100 Cadillac Court | |||
| Milpitas, CA 95035 | Milpitas, CA 95035 | |||
| Email: tli@procket.com | Email: tli@procket.com | |||
| Voice: +1 408 6357900 | Voice: +1 408 6357900 | |||
| Fax: +1 408 6356166 | Fax: +1 408 6356166 | |||
| Henk Smit | Henk Smit | |||
| Email: hhwsmit@freeler.nl | Email: hhwsmit@xs4all.nl | |||
| End of changes. 12 change blocks. | ||||
| 20 lines changed or deleted | 78 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||