RFC 7813
IS-IS Path Control and Reservation
Pages: 33
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 19 to 33
6.3. Bandwidth Constraint Sub-TLV
The Bandwidth Constraint sub-TLV MAY be included in a Topology sub- TLV (Section 6.1) in order to specify how much available bandwidth is to be provided by the constrained tree. Each loose hop MUST meet the bandwidth constraint. The bandwidth value of the constraint is a total value or it only refers to a single PCP as specified by the sub-TLV. Figure 4 shows the format of the Bandwidth Constraint sub- TLV.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | PCP |D|P| Res | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available Bandwidth (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Bandwidth Constraint Sub-TLV The parameters of the bandwidth constraint are encoded as follows: a. Type (8 bits): The type of the sub-TLV, its value is 23. b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes. c. PCP (4 bits): The Priority Code Point (PCP) parameter identifies the traffic class the Available Bandwidth parameter refers to, if any. d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter. If the DEI parameter is clear, then the bandwidth constraint refers to committed information rate. If the DEI parameter is set, then the bandwidth constraint refers to the peak information rate. e. PCP (P) flag (1 bit): If this flag is set, then the PCP parameter is taken into account. f. Reserved (Res) (3 bits): The reserved bits MUST be set to 0 on transmission, and the value MUST be ignored on reception. g. Available Bandwidth (32 bits): The Available Bandwidth is specific to the traffic class identified by the PCP parameter if the PCP flag is set; otherwise, it is total bandwidth. In line with the bandwidth parameters specified in [RFC5305], the Available Bandwidth is encoded as a 32-bit IEEE floating-point number [IEEE754], and the units are bytes (not bits!) per second. When the Unreserved Bandwidth sub-TLV (sub-TLV type 11 specified by [RFC5305]) is used in a Layer 2 bridge network, the priority value encoded in the Unreserved Bandwidth sub-TLV provides the PCP, i.e., identifies a traffic class (not a setup priority level). Thus, the Available Bandwidth of a traffic class is
easily comparable with the Unreserved Bandwidth stored in the TED
for the given traffic class. The bandwidth constraint applies
for both directions in case of symmetric explicit trees.
Nevertheless, a VID associated with an explicit tree can be made
unidirectional by means of the T/R flags belonging to the VID in
the Hop sub-TLV (item g. in Section 6.2) of the Edge Bridges. If
all the VIDs of the Topology sub-TLV (Section 6.1) are
unidirectional and all belong to the traffic class identified by
the PCP parameter of the Bandwidth Constraint sub-TLV, then it is
enough to meet the bandwidth constraint in the direction applied
for those VIDs.
6.4. Bandwidth Assignment Sub-TLV
IS-IS PCR MAY be used for recording bandwidth assignment for
explicitly placed data traffic in a domain if MSRP is not used within
the domain. If MSRP is used in a domain, then only MSRP performs
reservations and IS-IS does not. Both MSRP and IS-IS MUST NOT be
used to make bandwidth assignments in the same domain.
The Bandwidth Assignment sub-TLV can be used to define the amount of
bandwidth whose assignment is to be recorded by IS-IS PCR at each hop
of the explicit tree described by the corresponding Topology sub-TLV
(Section 6.1). The Bandwidth Assignment sub-TLV is used by IS-IS PCR
for the recording of bandwidth assignment for a traffic class
identified by the PCP parameter of a VLAN tag. If precedence order
has to be determined among bandwidth assignments in a domain with
multiple PCEs, then IS-IS PCR does it as described below. If the
bandwidth assignment specified by the Topology sub-TLV is not
possible, e.g., due to overbooking, then bandwidth recording MUST NOT
be performed and a management report is generated. If the Topology
sub-TLV specifies a new valid explicit tree, then the tree is
installed without bandwidth assignment. The Bandwidth Assignment
sub-TLV is conveyed by a Topology sub-TLV (Section 6.1). Figure 5
shows the format of the Bandwidth Assignment sub-TLV.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+ | PCP |D| Imp |R| (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Bandwidth Assignment Sub-TLV The parameters of the bandwidth assignment are encoded as follows: a. Type (8 bits): The type of the sub-TLV, its value is 24. b. Length (8 bits): The total number of bytes contained in the Value field. The value of the Length field is 5 bytes. c. PCP (3 bits): The PCP parameter identifies the traffic class for which the bandwidth is to be assigned. d. DEI (D) (1 bit): This is the Drop Eligible Indicator (DEI) parameter. If the DEI parameter is clear, then the bandwidth assignment is performed for providing the committed information rate. If the DEI parameter is set, then the bandwidth assignment is performed for providing the peak information rate. e. Importance (Imp) (3 bits): This is the Importance parameter for determining precedence order among bandwidth assignments within a PCP as described below. A lower numerical value indicates more important bandwidth assignment within a PCP. The default value of the Importance parameter is 7. f. Reserved (R) (1 bit): The reserved bit MUST be set to 0 on transmission, and the value MUST be ignored on reception. g. Bandwidth (32 bits): This is the amount of bandwidth to be assigned for the traffic class identified by the PCP parameter. In line with the bandwidth values specified in [RFC5305], the Bandwidth parameter is encoded as a 32-bit IEEE floating-point number [IEEE754], and the units are bytes (not bits!) per second. The bandwidth assignment applies for both directions in case of symmetric explicit trees.
The PCEs are collectively responsible for making a consistent set of bandwidth assignments when IS-IS PCR is used for recording bandwidth allocations. If, despite that, precedence ordering is required among bandwidth assignments, then ordering based on the following parameters MUST be applied: 1. PCP parameter of Bandwidth Assignment sub-TLV, 2. Importance parameter of Bandwidth Assignment sub-TLV, 3. Timestamp sub-TLV (if present in the Topology sub-TLV). A bandwidth assignment takes precedence if it has a higher PCP, or a higher Importance within a PCP, or an earlier timestamp in case of equal Importance within a PCP. A bandwidth assignment associated with a timestamp takes precedence over a bandwidth assignment without a timestamp when PCP and Importance of different bandwidth assignments are both equal. If resolution is not possible based on the above parameters or they are not available, e.g., each bandwidth assignment lacks a timestamp or the precedence order has to be determined for the use of a VID, then the item is granted to the PCE whose LSP has the numerically lowest LSP ID.6.5. Timestamp Sub-TLV
The Timestamp sub-TLV MAY be included in a Topology sub-TLV (Section 6.1) in order to provide precedence order among equally important bandwidth assignments within a PCP as described in Section 6.4. Figure 6 shows the format of the Timestamp sub-TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | (1 byte) +-+-+-+-+-+-+-+-+ | Length | (1 byte) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Timestamp Sub-TLV The timestamp represents a positive time with respect to the Precision Time Protocol (PTP) epoch, and it is encoded as follows: a. Type (8 bits): The type of the sub-TLV; its value is 25.
b. Length (8 bits): The total number of bytes contained in the Value
field. The value of the Length field is 4 bytes.
c. Time (32 bits): This is the time in units of seconds with respect
to the PTP epoch.
The Timestamp sub-TLV carries the seconds portion of PTP as specified
by [IEEE1588]. The epoch is 1970-01-01 00:00:00 TAI (i.e., the PTP
time does not include leap seconds).
7. MRT-FRR Application
The application of MRT by [IEEE8021Qca] is discussed in detail in
[MRT-IEEE8021qca]. This section describes some special
considerations for the use of the MRT Lowpoint algorithm [RFC7811],
which are applicable both to the MRT ECT Algorithm and the MRTG ECT
Algorithm. This section also explains details related to the MRTG
ECT Algorithm and the application of the Topology sub-TLV in
particular.
IS-IS PCR does not use the MRT Profile specified in [RFC7812]. IS-IS
PCR only relies on the algorithm specification in [RFC7811]. Both
the MRT ECT Algorithm and the MRTG ECT Algorithm use the MRT Lowpoint
algorithm specified in [RFC7811].
The SPB Link Metric sub-TLV [RFC6329] specifies the metric of each
link for IS-IS PCR including the MRT algorithms. If the SPB Link
Metric values advertised by different ends of an adjacency are
different, then the maximum value MUST be used. If equal cost
(sub-)paths are found during the MRT computation, then the default
tie-breaking specified by Section 11 of [RFC6329] MUST be used, which
is based on the lower BridgeID. (The BridgeID is an 8-byte quantity
whose upper 2 bytes are the node's BridgePriority and lower 6 bytes
are the node's System ID.) Note that if MRTs are used for source-
specific multicast (see [IEEE8021Qca] for details), then the bridges
have to compute the MRTs of the other bridges in addition to their
own in order to be able to install the appropriated FDB entries.
(This is similar to the need for all pairs shortest path computation
instead of Dijkstra for source-specific shortest path multicast
trees.)
The GADAG is identical for all the MRTs within a network domain, as a
consequence of the use of the MRT Lowpoint algorithm [RFC7811].
Therefore, it is beneficial to compute the GADAG by a single entity,
which is referred to as the GADAG Computer and is either a PCE or the
GADAG Root. If the MRTG ECT Algorithm is applied, then the GADAG
MUST be computed only by the GADAG Computer, which then MUST flood
the descriptor Topology sub-TLV of the GADAG. The bridges then compute the MRTs based on the received GADAG. The GADAG computation requires the selection of the GADAG Root. The bridge with the best BridgeID MUST be selected as the GADAG Root, where the numerically lower value indicates the better identifier. The Bridge Priority component of the BridgeID allows the configuration of the GADAG Root by management action. The Bridge Priority is conveyed by the SPB Instance sub-TLV [RFC6329]. The GADAG Computer MUST perform the GADAG computation as specified by the MRT Lowpoint algorithm [RFC7811]. The GADAG Computer then MUST encode the GADAG in a Topology sub-TLV (Section 6.1), which is then flooded throughout the domain. A GADAG is encoded in a Topology sub- TLV by means of directed ear decomposition as follows. A directed ear is a directed point-to-point path whose end points can coincide but no other element of the path is repeated in the ear. Each ear is specified by an ordered list of hops such that the order of hops is according to the direction of the arcs in the GADAG. There are no leaves in a GADAG; hence, the Leaf flag (item c.5. in Section 6.2) is used to mark the end of a topology block. (A GADAG with multiple blocks is illustrated in Figure 8.) The sequence of ears in the Topology sub-TLV is such that the end points of an ear belong to preceding ears. The GADAG Root is not marked by any flag, but the GADAG Root is the first hop in the Topology sub-TLV; correspondingly, the first ear starts and ends with the GADAG Root. MRT Roots MUST be marked by the Root flag (item c.4. in Section 6.2) and all other Edge Bridges are leaves of the given MRTs. If no MRT Root is specified, then each SPT Root is also an MRT Root. Figure 7 shows an example GADAG. The figure also illustrates the description of the GADAG; it shows the System ID parameter of the Hop sub-TLV (Section 6.2) and the order of hops in the Topology sub-TLV (Section 6.1).
Leaf Hop flag +-----------+---+ | A | | +-----------+---+ | B | | +-----------+---+ | C | | +-----------+---+ | F | | [B]<---[A]<---[I] +-----------+---+ | ^ ^ | A | | | | | +-----------+---+ V | | | C | | [C]--->[F]--->[H] +-----------+---+ | ^ | D | | | | +-----------+---+ V | | E | | [D]--->[E]--->[G] +-----------+---+ | G | | +-----------+---+ | H | | +-----------+---+ | I | | +-----------+---+ | A | | +-----------+---+ | F | | +-----------+---+ | H | X | +-----------+---+ Figure 7: A GADAG and Its Description; GADAG Root = Node A A topology can comprise multiple blocks, like the one illustrated in Figure 8(a). This example topology comprises four blocks as each cut-link is a block. A-B-C-D-E-F is a block, D-G is another block, G-H, and H-J-K are further blocks. A GADAG for this topology is shown in Figure 8(b). Note that two arcs with opposite directions represent a cut-link in a GADAG; see, for example, the cut-link between D and G. The encoding starts with the block (ADAG) involving the GADAG Root as illustrated in Figure 8. The first hop in the Topology sub-TLV is the GADAG Root (node A in this example). The ADAG of the first block is then described using the ear decomposition, as described above. In this example, the first block has been completely traversed at the second occurrence of node A in the GADAG descriptor. The end of a block is indicated by setting the Leaf flag for the last hop of the block, e.g., for the second
occurrence of node A in the example GADAG descriptor. The next node that appears in the GADAG descriptor (D in this case) is the localroot for the nodes in the next block. Continuing this process, the Leaf flag is set for the third occurrence of D, the third occurrence of G, and the third occurrence of H, each indicating the end of a block. The first hop of the first block is the GADAG Root, the fist hop in the rest of the blocks is the localroot. The position of the set Leaf flags helps to determine the localroot, which is the next hop. In the example GADAG descriptor, one can determine that A is the localroot for B, C, D, E, F (and A is the GADAG Root). D is the localroot for G. G is the localroot for H. And H is the localroot for J and K. The GADAG Root is assigned a localroot of None. Block IDs are reconstructed while parsing a Topology sub-TLV specifying a GADAG. The current Block ID starts at 0 and is assigned to the GADAG Root. A node appearing in the GADAG descriptor without a previously assigned Block ID value is assigned the current Block ID. And the current Block ID is incremented by 1 after processing the localroot of a block. Note that the localroot of a block will keep the Block ID of the first block in which it is assigned a Block ID. In the example in Figure 8, A has Block ID=0. B, C, D, E, and F have Block ID=1. G has Block ID=2. H has Block ID=3. J and K have Block ID=4.
Leaf Hop flag [F]--[E] +--[K] +-----------+---+ | | | | | A | | | | | | +-----------+---+ [A] [D]--[G]--[H] | | B | | | | | | +-----------+---+ | | | | | C | | [B]--[C] +--[J] +-----------+---+ | D | | (a) Topology +-----------+---+ | E | | +-----------+---+ | F | | +-----------+---+ | A | X | +-----------+---+ +-+ +-+ +-+ | D | | |F|<-|E| +--|K| +-----------+---+ +-+ +-+ | +-+ | G | | | ^ | ^ +-----------+---+ | | V | | D | X | V +-+ +-+ +-+ | +-----------+---+ +-+ | |->| |->| | | | G | | |A| |D| |G| |H| | +-----------+---+ +-+ | |<-| |<-| | | | H | | | +-+ +-+ +-+ | +-----------+---+ | ^ | | | G | X | V | | | +-----------+---+ +-+ +-+ | +-+ | H | | |B|->|C| +->|J| +-----------+---+ +-+ +-+ +-+ | J | | +-----------+---+ (b) GADAG | K | | +-----------+---+ | H | X | +-----------+---+ (c) GADAG Descriptor Figure 8: A GADAG with Cut-Links and Its Description; GADAG Root = Node A
8. Summary
This document specifies IS-IS sub-TLVs for the control of explicit trees in Layer 2 networks. These sub-TLVs can be also used for the distribution of a centrally computed GADAG or MRTs if MFT-FRR is used.9. IANA Considerations
This document defines the following IS-IS sub-TLVs within the MT-Capability TLV (type 144). They are listed in the "IS-IS TLV Codepoints" registry. Type Description Length ---- ---------------------------- -------- 21 Topology variable 22 Hop variable 23 Bandwidth Constraint 5 24 Bandwidth Assignment 5 25 Timestamp 410. Security Considerations
This document adds no additional security risks to IS-IS, nor does it provide any additional security for IS-IS when used in a configured environment or a single-operator domain such as a data center. IS-IS PCR is not for zero-configuration environments. Any mechanism that chooses forwarding paths, and allocates resources to those paths, is potentially vulnerable to attack. The security considerations section of [RFC4655] describes the risks associated with the use of PCE for this purpose and should be referred to. Use of any other means to determine paths should only be used after considering similar concerns. Because the mechanism assumed for distributing tree information relies on IS-IS routing, IS-IS routing security considerations (Section 6, [RFC1195]) and mechanisms (e.g., [RFC5310]) used to authenticate peer advertisements apply.
11. References
11.1. Normative References
[IEEE8021Qca] IEEE, "IEEE Standard for Local and metropolitan area networks - Bridges and Bridged Networks - Amendment 24: Path Control and Reservation", IEEE 802.1Qca-2015, DOI 10.1109/IEEESTD.2016.7434544, 2016, <https://standards.ieee.org/findstds/ standard/802.1Qca-2015.html>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, DOI 10.17487/RFC5303, October 2008, <http://www.rfc-editor.org/info/rfc5303>. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>. [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>. [RFC6329] Fedyk, D., Ed., Ashwood-Smith, P., Ed., Allan, D., Bragg, A., and P. Unbehagen, "IS-IS Extensions Supporting IEEE 802.1aq Shortest Path Bridging", RFC 6329, DOI 10.17487/RFC6329, April 2012, <http://www.rfc-editor.org/info/rfc6329>. [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <http://www.rfc-editor.org/info/rfc7810>. [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, DOI 10.17487/RFC7811, June 2016, <http://www.rfc-editor.org/info/rfc7811>.
11.2. Informative References
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, 2008, <http://standards.ieee.org/findstds/ standard/1588-2008.html>. [IEEE754] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2008, DOI 10.1109/IEEESTD.2008.4610935, 2008, <http://standards.ieee.org/findstds/ standard/754-2008.html>. [IEEE8021aq] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks -- Amendment 20: Shortest Path Bridging", IEEE 802.1aq-2012, DOI 10.1109/IEEESTD.2012.6231597, 2012, <https://standards.ieee.org/findstds/ standard/802.1aq-2012.html>. [IEEE8021Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, 2014, <https://standards.ieee.org/findstds/ standard/802.1Q-2014.html>. [MRT-IEEE8021qca] Bowers, C. and J. Farkas, "Applicability of Maximally Redundant Trees to IEEE 802.1Qca Path Control and Reservation", Work in Progress, draft-bowers-rtgwg-mrt- applicability-to-8021qca-01, July 2015. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, <http://www.rfc-editor.org/info/rfc1195>. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>. [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, <http://www.rfc-editor.org/info/rfc7812>.Acknowledgements
The authors would like to thank Don Fedyk and Eric Gray for their comments and suggestions.Authors' Addresses
Janos Farkas (editor) Ericsson Konyves Kalman krt. 11/B Budapest 1097 Hungary Email: janos.farkas@ericsson.com Nigel Bragg Ciena 43-51 Worship Street London EC2A 2DX United Kingdom Email: nbragg@ciena.com Paul Unbehagen Jr Avaya 1300 W. 120th Avenue Westminster, CO 80234 United States Email: unbehagen@avaya.com Glenn Parsons Ericsson 349 Terry Fox Drive Ottawa ON, K2K 2V6 Canada Email: glenn.parsons@ericsson.com
Peter Ashwood-Smith Huawei Technologies 303 Terry Fox Drive, Suite 400 Ottawa ON, K2K 3J1 Canada Email: Peter.AshwoodSmith@huawei.com Chris Bowers Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States Email: cbowers@juniper.net