Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7813

IS-IS Path Control and Reservation

Pages: 33
Proposed Standard
Part 2 of 2 – Pages 19 to 33
First   Prev   None

Top   ToC   RFC7813 - Page 19   prevText

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.
Top   ToC   RFC7813 - Page 20
      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
Top   ToC   RFC7813 - Page 21
       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.
Top   ToC   RFC7813 - Page 22
      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.
Top   ToC   RFC7813 - Page 23
   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.
Top   ToC   RFC7813 - Page 24
   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
Top   ToC   RFC7813 - Page 25
   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).
Top   ToC   RFC7813 - Page 26
                                                       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
Top   ToC   RFC7813 - Page 27
   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.
Top   ToC   RFC7813 - Page 28
                                                       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
Top   ToC   RFC7813 - Page 29

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 4

10. 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.
Top   ToC   RFC7813 - Page 30

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>.
Top   ToC   RFC7813 - Page 31

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>.
Top   ToC   RFC7813 - Page 32
   [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
Top   ToC   RFC7813 - Page 33
   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