tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7813

 
 
 

IS-IS Path Control and Reservation

Part 2 of 2, p. 19 to 33
Prev Section

 


prevText      Top      ToC       Page 19 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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