< draft-ietf-isis-traffic-01.txt   draft-ietf-isis-traffic-02.txt >
Network Working Group Henk Smit Network Working Group Tony Li
INTERNET DRAFT Cisco Systems INTERNET DRAFT Procket Networks
Tony Li Henk Smit
Juniper Networks Procket Networks
May 1999 September 2000
IS-IS extensions for Traffic Engineering IS-IS extensions for Traffic Engineering
<draft-ietf-isis-traffic-01.txt> <draft-ietf-isis-traffic-02.txt>
Status Status
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted. 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-
skipping to change at page 2, line 28 skipping to change at line 68
the characteristics of a particular link to an IS-IS's LSP. the characteristics of a particular link to an IS-IS's LSP.
Secondary goals include increasing the dynamic range of the IS-IS Secondary goals include increasing the dynamic range of the IS-IS
metric and improving the encoding of IP prefixes. The router id is metric and improving the encoding of IP prefixes. The router id is
useful for traffic engineering purposes because it describes a single useful for traffic engineering purposes because it describes a single
address that can always be used to reference a particular router. address that can always be used to reference a particular router.
This document is a publication of the IS-IS Working Group within the 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 IETF, and is a contribution to ISO IEC JTC1/SC6, for eventual
inclusion with ISO 10589. inclusion with ISO 10589.
3.0 The router ID TLV 3.0 The Traffic Engineering router ID TLV
The router ID TLV is TLV type 134. The Traffic Engineering router ID TLV is TLV type 134.
The router ID TLV contains the 4-octet router ID of the router The router ID TLV contains the 4-octet router ID of the router
originating the LSP. This is useful in several regards: originating the LSP. This is useful in several regards:
For traffic engineering, it guarantees that we have a single stable For traffic engineering, it guarantees that we have a single stable
address that can always be referenced in a path that will be address that can always be referenced in a path that will be
reachable from multiple hops away, regardless of the state of the reachable from multiple hops away, regardless of the state of the
node's interfaces. node's interfaces.
If OSPF is also active in the domain, traffic engineering can compute If OSPF is also active in the domain, traffic engineering can compute
the mapping between the OSPF and IS-IS topologies. the mapping between the OSPF and IS-IS topologies.
If a router advertises the Traffic Engineering router ID TLV in its
LSP, and if it advertises BGP routes 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 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.
4.0 The extended IP reachability TLV 4.0 The extended IP reachability TLV
The extended IP reachability TLV is TLV type 135. The extended IP reachability TLV is TLV type 135.
The existing IP reachability TLV is a single TLV that carries IP The existing IP reachability TLV is a single TLV that carries IP
prefixes in a format that is analogous to the IS neighbor TLV. It prefixes in a format that is analogous to the IS neighbor TLV. It
skipping to change at page 3, line 31 skipping to change at line 118
one area back into level two. This problem occurs because the path one area back into level two. This problem occurs because the path
that the information can take forms a loop. The likely result is a that the information can take forms a loop. The likely result is a
forwarding loop. forwarding loop.
To address these issues, the proposed extended IP reachability TLV To address these issues, the proposed extended IP reachability TLV
provides for a 32 bit metric and adds one bit to indicate that a provides for a 32 bit metric and adds one bit to indicate that a
prefix has been redistributed 'down' in the hierarchy. prefix has been redistributed 'down' in the hierarchy.
The proposed extended IP reachability TLV contains a new data The proposed extended IP reachability TLV contains a new data
structure, consisting of: structure, consisting of:
4 bytes of metric information 4 bytes of metric information
1 byte of control information, consisting of 1 byte of control information, consisting of
1 bit of up/down information 1 bit of up/down information
1 bit indicating the existence of sub-TLVs 1 bit indicating the existence of sub-TLVs
6 bits of prefix length 6 bits of prefix length
0-4 bytes of IPv4 prefix 0-4 bytes of IPv4 prefix
0-250 optional octets of sub-TVLs, if present consisting of 0-250 optional octets of sub-TVLs, if present consisting of
1 octet of length of sub-TLVs 1 octet of length of sub-TLVs
0-249 octets of sub-TLVs 0-249 octets of sub-TLVs
This data structure can be replicated within the TLV, not to exceed This data structure can be replicated within the TLV, not to exceed
the maximum length of the TLV. the maximum length of the TLV.
The up/down bit shall be set to 0 when a prefix is first injected The up/down bit shall be set to 0 when a prefix is first injected
into IS-IS. If a prefix is redistributed from a higher level to a into IS-IS. If a prefix is redistributed from a higher level to a
lower level (e.g. level two to level one), the bit shall be set to 1, lower level (e.g. level two to level one), the bit shall be set to 1,
to indicate that the prefix has travelled down the hierarchy. to indicate that the prefix has travelled down the hierarchy.
Prefixes that have the up/down bit set to 1 must not be Prefixes that have the up/down bit set to 1 must not be
redistributed. If a prefix is redistributed from an area to another redistributed. If a prefix is redistributed from an area to another
skipping to change at page 5, line 23 skipping to change at line 204
on a LAN interface. Thus, the existing TLV consumes 11 octets per on a LAN interface. Thus, the existing TLV consumes 11 octets per
neighbor, with 4 octets for metric and 7 octets for neighbor neighbor, with 4 octets for metric and 7 octets for neighbor
identification. To indicate multiple adjacencies, this structure is identification. To indicate multiple adjacencies, this structure is
repeated within the IS reachability TLV. Because the TLV is limited repeated within the IS reachability TLV. Because the TLV is limited
to 255 octets of content, a single TLV can describe up to 23 to 255 octets of content, a single TLV can describe up to 23
neighbors. The IS reachability TLV can be repeated within the LSP neighbors. The IS reachability TLV can be repeated within the LSP
fragments to describe further neighbors. fragments to describe further neighbors.
The proposed extended IS reachability TLV contains a new data The proposed extended IS reachability TLV contains a new data
structure, consisting of structure, consisting of
7 octets of system Id and pseudonode number 7 octets of system Id and pseudonode number
3 octets of default metric 3 octets of default metric
1 octet of length of sub-TLVs 1 octet of length of sub-TLVs
0-244 octets of sub-TLVs 0-244 octets of sub-TLVs
Thus, if no sub-TLVs are used, the new encoding requires 11 octets Thus, if no sub-TLVs are used, the new encoding requires 11 octets
and can contain up to 23 neighbors. Please note that while the and can contain up to 23 neighbors. Please note that while the
encoding allows for 255 octets of sub-TLVs, the maximum value cannot encoding allows for 255 octets of sub-TLVs, the maximum value cannot
fit in the overall IS reachability TLV. The practical maximum is 255 fit in the overall IS reachability TLV. The practical maximum is 255
octets minus the 11 octets described above, or 244 octets. Further, octets minus the 11 octets described above, or 244 octets. Further,
there is no defined mechanism for extending the sub-TLV space for a there is no defined mechanism for extending the sub-TLV space for a
particular neighbor. Thus, wasting sub-TLV space is discouraged. particular neighbor. Thus, wasting sub-TLV space is discouraged.
The metric octets are encoded as a 24-bit unsigned integer. To The metric octets are encoded as a 24-bit unsigned integer. Note that
preclude overflow within an SPF implementation, all metrics greater the metric field in the new extended IP reachability TLV is encoded
than or equal to MAX_PATH_METRIC shall be considered to have a metric as a 32-bit unsigned integer. These different sizes were chosen so
of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC such that it is very unlikely that the cost of an intra-area route has to
that MAX_PATH_METRIC plus a single link metric does not overflow the be chopped off to fit in the metric field of an inter-area route.
number of bits for internal metric calculation. We assume that this
is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, 2^32 To preclude overflow within an SPF implementation, all metrics
- 2^25). greater than or equal to MAX_PATH_METRIC shall be considered to have
a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC
such that MAX_PATH_METRIC plus a single link metric does not overflow
the number of bits for internal metric calculation. We assume that
this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,
2^32 - 2^25).
If a link is advertised with the maximum link metric (2^24 - 1), this If a link is advertised with the maximum link metric (2^24 - 1), this
link should not be considered during the normal SPF computation. link should not be considered during the normal SPF computation.
This will allow advertisment of a link for other purposes than This will allow advertisment of a link for other purposes than
building the normal Shortest Path Tree. An example is a link that is building the normal Shortest Path Tree. An example is a link that is
available for traffic engineering, but not for hop-by-hop routing. available for traffic engineering, but not for hop-by-hop routing.
Certain sub-TLVs are proposed here: Certain sub-TLVs are proposed here:
Sub-TLV type Length (octets) Name
Sub-TLV type Length (octets) Name 3 4 Administrative group (color)
3 4 Administrative group (color) 6 4 IPv4 interface address
6 4 IPv4 interface address 8 4 IPv4 neighbor address
8 4 IPv4 neighbor address 9 4 Maximum link bandwidth
9 4 Maximum link bandwidth 10 4 Reservable link bandwidth
10 4 Reservable link bandwidth 11 32 Unreserved bandwidth
11 32 Unreserved bandwidth 18 3 TE Default metric
18 3 TE Default metric 250-254 Reserved for cisco specific extensions
250-254 Reserved for cisco specific 255 Reserved for future expansion
extensions
255 Reserved for future expansion
Each of these sub-TLVs is described below. Unless stated otherwise, Each of these sub-TLVs is described below. Unless stated otherwise,
multiple occurrences of the information are supported by multiple multiple occurrences of the information are supported by multiple
inclusions of the sub-TLV. inclusions of the sub-TLV.
5.1 Sub-TLV 3: Administrative group (color, resource class) 5.1 Sub-TLV 3: Administrative group (color, resource class)
The administrative group sub-TLV contains a 4-octet bit mask assigned The administrative group sub-TLV contains a 4-octet bit mask assigned
by the network administrator. Each set bit corresponds to one by the network administrator. Each set bit corresponds to one
administrative group assigned to the interface. administrative group assigned to the interface.
By convention the least significant bit is referred to as 'group 0', By convention the least significant bit is referred to as 'group 0',
and the most significant bit is referred to as 'group 31'. and the most significant bit is referred to as 'group 31'.
5.2 Sub-TLV 6: IPv4 interface address 5.2 Sub-TLV 6: IPv4 interface address
This sub-TLV contains a 4-octet IPv4 address for the interface This sub-TLV contains a 4-octet IPv4 address for the interface
described by the (main) TLV. This sub-TLV can occur multiple times. described by the (main) TLV. This sub-TLV can occur multiple times.
If the interface being advertised for Traffic Engineering purposes is
unnumbered, the IPv4 interface address sub-TLV is set to the router
ID of the advertising router. In combination with the IPv4 neighbor
address sub-TLV this identifies the unnumbered link over which the
advertised adjacency has been established.
Implementations MUST NOT inject a /32 prefix for the interface Implementations MUST NOT inject a /32 prefix for the interface
address into their routing or forwarding table, because this can lead address into their routing or forwarding table, because this can lead
to forwarding loops when interacting with systems that do not support to forwarding loops when interacting with systems that do not support
this sub-TLV. this sub-TLV.
If a router implements the basic TLV extensions in this document, it If a router implements the basic TLV extensions in this document, it
is free to add or omit this sub-TLV to the description of an is free to add or omit this sub-TLV to the description of an
adjacency. If a router implements traffic engineering, it must adjacency. If a router implements traffic engineering, it must
include this sub-TLV. include this sub-TLV.
5.3 Sub-TLV 8: IPv4 neighbor address 5.3 Sub-TLV 8: IPv4 neighbor address
This sub-TLV contains a single IPv4 address for a neighboring router This sub-TLV contains a single IPv4 address for a neighboring router
on this link. This sub-TLV can occur multiple times. on this link. This sub-TLV can occur multiple times.
If the interface being advertised for Traffic Engineering purposes is
unnumbered, the first two octets of the IPv4 neighbor address sub-TLV
are set to zero and the next two octets are set to the interface ID
of the unnumbered interface. In combination with the IPv4 interface
address sub-TLV this identifies the unnumbered link over which the
advertised adjacency has been established.
Implementations MUST NOT inject a /32 prefix for the neighbor address Implementations MUST NOT inject a /32 prefix for the neighbor address
into their routing or forwarding table, because this can lead to into their routing or forwarding table, because this can lead to
forwarding loops when interacting with systems that do not support forwarding loops when interacting with systems that do not support
this sub-TLV. this sub-TLV.
If a router implements the basic TLV extensions in this document, it If a router implements the basic TLV extensions in this document, it
is free to add or omit this sub-TLV to the description of an is free to add or omit this sub-TLV to the description of an
adjacency. If a router implements traffic engineering, it must adjacency. If a router implements traffic engineering, it must
include this sub-TLV on point-to-point adjacencies. include this sub-TLV on point-to-point adjacencies.
skipping to change at page 8, line 30 skipping to change at line 357
To preclude overflow within an SPF implementation, all metrics To preclude overflow within an SPF implementation, all metrics
greater than or equal to MAX_PATH_METRIC shall be considered to have greater than or equal to MAX_PATH_METRIC shall be considered to have
a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC a metric of MAX_PATH_METRIC. It is easiest to select MAX_PATH_METRIC
such that MAX_PATH_METRIC plus a single link metric does not overflow such that MAX_PATH_METRIC plus a single link metric does not overflow
the number of bits for internal metric calculation. We assume that the number of bits for internal metric calculation. We assume that
this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000, this is 32 bits. Thus, MAX_PATH_METRIC is 4,261,412,864 (0xFE000000,
2^32 - 2^25). 2^32 - 2^25).
If a link is advertised without this sub-TLV, traffic engineering SPF If a link is advertised without this sub-TLV, traffic engineering SPF
calculations must use the normal default metric of this link, which calculations must use the normal default metric of this link, which
is advertised in the fixed part of TLV 22. is advertised in the fixed part of the extended IS reachability TLV.
6.0 Security Considerations 6.0 Security Considerations
This document raises no new security issues for IS-IS. This document raises no new security issues for IS-IS.
7.0 Acknowledgments 7.0 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.
8.0 References 8.0 References
[1] draft-ietf-mpls-traffic-eng-00.txt, "Requirements for Traffic [1] RFC 2702, "Requirements for Traffic Engineering Over MPLS," D.
Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, and J. McManus, September
O'Dell, J. McManus, work in progress. 1999.
[2] ISO 10589, "Intermediate System to Intermediate System Intra- [2] ISO 10589, "Intermediate System to Intermediate System Intra-
Domain Routeing Exchange Protocol for use in Conjunction with the Domain Routeing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Service (ISO Protocol for Providing the Connectionless-mode Network Service (ISO
8473)" [Also republished as RFC 1142] 8473)" [Also republished as RFC 1142]
[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, Dec. 1990 environments", R.W. Callon, Dec. 1990
9.0 Authors' Addresses 9.0 Authors' Addresses
Henk Smit Tony Li
Cisco Systems, Inc. Procket Networks, Inc.
210 West Tasman Drive 3850 North First Street
San Jose, CA 95134 San Jose, CA 95134
Email: hsmit@cisco.com Email: tli@procket.com
Voice: +31 20 342 3736 Voice: +1 408 9547900
Fax: +1 408 9876166
Tony Li Henk Smit
Juniper Networks, Inc. Procket Networks, Inc.
385 Ravendale Dr. 3850 North First Street
Mountain View, CA 94043 San Jose, CA 95134
Email: tli@juniper.net Email: henk@procket.com
Fax: +1 650 526 8001 Voice: +1 408 9547900
Voice: +1 650 526 8006 Fax: +1 408 9876166
 End of changes. 16 change blocks. 
50 lines changed or deleted 72 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/