tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8104

 
 
 

Pseudowire (PW) Endpoint Fast Failure Protection

Part 2 of 2, p. 29 to 43
Prev Section

 


prevText      Top      ToC       Page 29 
5.  Restorative and Revertive Behaviors

   Subsequent to local repair, there are three strategies for a network
   to restore traffic to a fully functional alternative path:

   o  Global repair

      If the ingress CE is multihomed (Figure 1), it MAY switch the
      traffic to the backup AC, which is bound to the backup PW.
      Alternatively, if the ingress PE hosts a backup PW (Figure 2), the
      ingress PE MAY switch the traffic to the backup PW.  These
      procedures are referred to as global repair.  Possible triggers of
      global repair include PW status notification, Virtual Circuit
      Connectivity Verification (VCCV) [RFC5085] [RFC5885], BFD,
      end-to-end OAM between CEs, and others.

   o  Control-plane convergence

      In egress PE node protection and S-PE node protection, it is
      possible that the failure is limited to the link between the PLR
      and the primary PE, whereas the primary PE is still operational.
      In this case, the PLR or an upstream router on the transport
      tunnel MAY reroute the tunnel around the link via an alternative
      path to the primary PE.  Thus, the transport tunnel can heal and
      continue to carry the PW to the primary PE.  This procedure is
      driven by control-plane convergence on the new topology.

   o  Local reversion

      The PLR MAY move traffic back to the primary PW, after the failure
      is resolved.  In egress AC protection, upon detecting that the
      primary AC is restored, the PLR MAY start forwarding traffic over
      the AC again.  Likewise, in egress PE node protection and S-PE
      node protection, upon detecting that the primary PE is restored,
      the PLR MAY re-establish the transport tunnel to the primary PE
      and move the traffic from the bypass tunnel back to the transport
      tunnel.  These procedures are referred to as local reversion.

Top      Up      ToC       Page 30 
   It is RECOMMENDED that the fast protection mechanism SHOULD be used
   in conjunction with global repair.  Particularly in the case of
   egress PE and S-PE node failures, if the ingress PE or the protector
   loses communication with the egress PE or S-PE for an extensive
   period of time, the LDP session may go down.  Consequently, the
   ingress PE may bring down the primary PW completely, or the protector
   may remove the forwarding entry of the primary PW label.  In either
   case, the service will be disrupted.  In other words, although the
   mechanism can temporarily repair traffic, control-plane state may
   eventually expire if the failure persists.  Therefore, global repair
   SHOULD take place in a timely manner to move traffic to a fully
   functional alternative path.

   Control-plane convergence may automatically happen as control-plane
   protocols react to the new topology.  However, it is only applicable
   to the specific link failure scenario described above.

   Local reversion is optional.  In the circumstances where the failure
   is caused by resource flapping, local reversion MAY be dampened to
   limit potential disruption.  Local reversion MAY be disabled
   completely by configuration.

6.  LDP Extensions

   As described in previous sections, a targeted LDP session MUST be
   established between each pair of primary PE and protector.  The
   primary PE sends a Label Mapping message over this session to
   advertise primary PW labels to the protector.  In the centralized
   protector model, a targeted LDP session MUST also be established
   between a backup (S-)PE and the protector.  The backup PE sends a
   Label Mapping message over this session to advertise backup PW labels
   to the protector.

   To support the procedures, this document defines a new "Protection
   FEC Element" TLV.  The Label Mapping messages of both the LDP
   sessions above MUST carry this TLV to identify a primary PW.
   Specifically, in the centralized protector model, the Protection FEC
   Element TLV advertised by a backup (S-)PE MUST match the one
   advertised by the primary PE, so that the protector can associate the
   primary PW's label with the backup PW's label and perform a label
   swap.  The backup (S-)PE builds such a Protection FEC Element TLV
   based on local configuration.

   This document also defines a new "Egress Protection Capability" TLV
   as a new type of Capability Parameter TLV [RFC5561], to allow a
   protector to announce its capability of processing the above
   Protection FEC Element TLV and performing context-specific label
   switching for PW labels.

Top      Up      ToC       Page 31 
   The procedures in this section are only applicable if the protector
   advertises the Egress Protection Capability TLV, the primary PE
   supports the advertisement of the Protection FEC Element TLV, and in
   the centralized protector model, the backup PE also supports the
   advertisement of the Protection FEC Element TLV.

6.1.  Egress Protection Capability TLV

   A protector MUST advertise the Egress Protection Capability TLV in
   its Initialization message and Capability message over the LDP
   session with a primary PE.  In the centralized protector model, the
   protector MUST also advertise the TLV over the LDP session with a
   backup PE.  The TLV carries one or multiple context identifiers.  To
   the primary PE, the TLV MUST carry the context identifier of the
   {primary PE, protector}.  In the centralized protector model, the TLV
   MUST carry multiple context identifiers to the backup PE, one for
   each {primary PE, protector} where the backup PE serves as a backup
   for the primary PE.  This TLV MUST NOT be advertised by the primary
   PE or the backup PE to the protector.

   The processing of the Egress Protection Capability TLV by a receiving
   router MUST follow the procedures defined in [RFC5561].  In
   particular, the router MUST advertise PW information to the protector
   by using the Protection FEC Element TLV, only after it has received
   the Egress Protection Capability TLV from the protector.  It MUST
   validate each context identifier included in the TLV and advertise
   the information of only the PWs that are associated with the context
   identifier.  It MUST withdraw previously advertised Protection FEC
   TLVs, when the protector has withdrawn a previously advertised
   context identifier or the entire Egress Protection Capability TLV via
   a Capability message.

   The encoding of the Egress Protection Capability TLV is defined
   below.  It conforms to the format of Capability Parameter TLV
   specified in [RFC5561].

Top      Up      ToC       Page 32 
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| Egress Protection (0x0974)|              Length           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S| Reserved    |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     ~                Capability Data = context identifier(s)        ~
     |                                                               |
     |                                               +-+-+-+-+-+-+-+-+
     |                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 15

   The U-bit MUST be set to 1, so that a receiver MUST silently ignore
   this TLV if unknown to it and continue processing the rest of the
   message.

   The F-bit MUST be set to 0 since this TLV is sent only in
   Initialization and Capability messages, which are not forwarded.

   The TLV code point is 0x0974.

   The S-bit indicates whether the sender is advertising (S=1) or
   withdrawing (S=0) the capability.

   The Capability Data field is encoded with the context identifiers of
   the {primary PE, protector} pairs for which the advertiser is the
   protector.

6.2.  PW Label Distribution from Primary PE to Protector

   A primary PE MUST advertise a primary PW's label to a protector by
   sending a Label Mapping message.  The message includes a Protection
   FEC Element TLV (see Section 6.4 for encoding) and an Upstream-
   Assigned Label TLV [RFC6389] encoded with the PW's label.  The
   combination of the Protection FEC Element TLV and the PW label
   represents the primary PE's forwarding state for the PW.  The Label
   Mapping message MUST also carry an IPv4/v6 Interface_ID TLV [RFC3471]
   [RFC6389] encoded with the context identifier of the {primary PE,
   protector}.

   The protector that receives this Label Mapping message MUST install a
   forwarding entry for the PW label in the label space identified by
   the context identifier.  The next hop of the forwarding entry MUST
   ensure that packets are sent towards the target CE via a backup AC or

Top      Up      ToC       Page 33 
   a backup (S-)PE, depending on the protection scenario.  The protector
   MUST silently discard a Label Mapping message if the included context
   identifier is unknown to it.

6.3.  PW Label Distribution from Backup PE to Protector

   In the centralized protector model, a backup PE MUST advertise a
   backup PW's label to the protector by sending a Label Mapping
   message.  The message includes a Protection FEC Element TLV and a
   Generic Label TLV encoded with the backup PW's label.  This
   Protection FEC Element MUST be identical to the Protection FEC
   Element TLV that the primary PE advertises to the protector
   (Section 6.2).  This is achieved through configuration on the backup
   PE.  The context identifier MUST NOT be encoded in an Interface_ID
   TLV in this message.

   The protector that receives this Label Mapping message MUST associate
   the backup PW with the primary PW, based on the common Protection FEC
   Element TLV.  It MUST distinguish between the Label Mapping message
   from the primary PE and the Label Mapping message from the backup PE
   based on the respective presence and absence of a context identifier
   in the Interface_ID TLV.  It MUST install a forwarding entry for the
   primary PW's label in the label space identified by the context
   identifier.  The next hop of the forwarding entry MUST indicate a
   label swap to the backup PW's label, followed by a label push or IP
   header push for a transport tunnel to the backup PE.

Top      Up      ToC       Page 34 
6.4.  Protection FEC Element TLV

   The Protection FEC Element TLV has type 0x83.  Its format is defined
   below:

      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(0x83)  |    Reserved   | Encoding Type |    Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                                                               |
     ~                         PW Information                        ~
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 16

   -  Encoding Type

      Type of encoding format of the PW Information field.  The
      following types are defined, corresponding to the PWid FEC Element
      and Generalized PWid FEC Element defined in [RFC8077].

      1 - PWid FEC Element with IPv4 PE addresses (Section 6.4.1).

      2 - Generalized PWid FEC Element with IPv4 PE addresses
          (Section 6.4.2).

      3 - PWid FEC Element with IPv6 PE addresses (Section 6.4.3).

      4 - Generalized PWid FEC Element with IPv6 PE addresses
          (Section 6.4.4).

   -  Length

      Length of the PW Information field in octets.

   -  PW Information

      Field of variable length that specifies a PW.

Top      Up      ToC       Page 35 
6.4.1.  Encoding Format for PWid with IPv4 PE Addresses

      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(0x83)  |    Reserved   |  Enc Type(1)  |   Length(20)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Ingress PE IPv4 Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Egress PE IPv4 Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Group ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             PW ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 17

   -  Ingress PE IPv4 Address

      IPv4 address of the ingress PE of PW.

   -  Egress PE IPv4 Address

      IPv4 address of the egress PE of PW.

   -  Group ID

      An arbitrary 32-bit value that represents a group of PWs and that
      is used to create groups in the PW space.

   -  PW ID

      A non-zero 32-bit connection ID that, together with the PW Type
      field, identifies a particular PW.

   -  Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If
      C = 1, control word is present; if C = 0, control word is not
      present.

   -  PW Type

      A 15-bit quantity that represents the type of PW.

Top      Up      ToC       Page 36 
6.4.2.  Encoding Format for Generalized PWid with IPv4 PE Addresses

      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(0x83)  |    Reserved   |  Enc Type(2)  |   Length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Ingress PE IPv4 Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Egress PE IPv4 Address                   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AGI Type    |    Length     |          AGI Value            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                    AGI Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    AII Type   |    Length     |         SAII Value            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   SAII  Value (contd.)                        ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    AII Type   |    Length     |         TAII Value            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   TAII Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 18

   -  Ingress PE IPv4 Address

      IPv4 address of the ingress PE of PW.

   -  Egress PE IPv4 Address

      IPv4 address of the egress PE of PW.

   -  Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If
      C = 1, control word is present; if C = 0, control word is not
      present.

   -  PW Type

      A 15-bit quantity that represents the type of PW.

Top      Up      ToC       Page 37 
   -  AGI Type, Length, AGI Value

      Attachment Group Identifier of PW.

   -  AII Type, Length, SAII Value

      Source Attachment Individual Identifier of PW.

   -  AII Type, Length, TAII Value

      Target Attachment Individual Identifier of PW.

6.4.3.  Encoding Format for PWid with IPv6 PE Addresses

      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(0x83)  |    Reserved   |  Enc Type(3)  |   Length(44)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                     Ingress PE IPv6 Address                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                      Egress PE IPv6 Address                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Group ID                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             PW ID                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 19

   -  Ingress PE IPv6 Address

      IPv6 address of the ingress PE of PW; 16 octets.

   -  Egress PE IPv6 Address

      IPv6 address of the egress PE of PW; 16 octets.

   -  Group ID

      An arbitrary 32-bit value that represents a group of PWs and that
      is used to create groups in the PW space.

Top      Up      ToC       Page 38 
   -  PW ID

      A non-zero 32-bit connection ID that, together with the PW Type
      field, identifies a particular PW.

   -  Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If
      C = 1, control word is present; if C = 0, control word is not
      present.

   -  PW Type

      A 15-bit quantity that represents the type of PW.

6.4.4.  Encoding Format for Generalized PWid with IPv6 PE Addresses

      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(0x83)  |    Reserved   |  Enc Type(4)  |   Length      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                     Ingress PE IPv6 Address                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                      Egress PE IPv6 Address                   ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |C|           PW Type           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   AGI Type    |    Length     |          AGI Value            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                    AGI Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    AII Type   |    Length     |         SAII Value            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   SAII Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    AII Type   |    Length     |         TAII Value            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                   TAII Value (contd.)                         ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 20

Top      Up      ToC       Page 39 
   -  Ingress PE IPv6 Address

      IPv6 address of the ingress PE of PW; 16 octets.

   -  Egress PE IPv6 Address

      IPv6 address of the egress PE of PW; 16 octets.

   -  Control word bit (C)

      A bit that flags the presence of a control word on this PW.  If
      C = 1, control word is present; if C = 0, control word is not
      present.

   -  PW Type

      A 15-bit quantity that represents the type of PW.

   -  AGI Type, Length, AGI Value

      Attachment Group Identifier of PW.

   -  AII Type, Length, SAII Value

      Source Attachment Individual Identifier of PW.

   -  AII Type, Length, TAII Value

      Target Attachment Individual Identifier of PW.

7.  IANA Considerations

   This document defines a new Egress Protection Capability TLV in
   Section 6.  IANA has assigned value 0x0974 for it in the "TLV Type
   Name Space" registry.

   This document defines a new Protection FEC Element TLV in Section 6.
   IANA assigned value 0x83 for it in the "Forwarding Equivalence Class
   (FEC) Type Name Space" registry per RFC 7358.  IANA has updated the
   registry to also reference this document.

Top      Up      ToC       Page 40 
8.  Security Considerations

   In this document, PW traffic can be temporarily rerouted by a PLR to
   a protector.  In the centralized protector scenario, the traffic can
   be further rerouted to a backup PE.  In the control plane, there is a
   targeted LDP session between a primary PE and a protector.  In the
   centralized protector scenario, there is also a targeted LDP session
   between a backup PE and a protector.  In all scenarios, traffic
   rerouting via PLRs, protectors, and backup PEs is planned and
   anticipated, and backup PEs can be used anyway to host PWs and LDP
   sessions.  Hence, the rerouted traffic and the LDP sessions
   introduced in this document should not be viewed as a new security
   threat.

   In general, [RFC5920] describes the security framework for MPLS
   networks.  [RFC3209] describes the security considerations for RSVP
   Label Switched Paths (LSPs).  [RFC5036] describes the security
   considerations for the base LDP specification.  [RFC5561] describes
   the security considerations that apply when using the LDP capability
   mechanism.  All these security frameworks and considerations apply to
   this document as well.

9.  References

9.1.  Normative References

   [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>.

   [RFC8077]  Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
              Maintenance Using the Label Distribution Protocol (LDP)",
              STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
              <http://www.rfc-editor.org/info/rfc8077>.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, DOI 10.17487/RFC5331, August 2008,
              <http://www.rfc-editor.org/info/rfc5331>.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561,
              DOI 10.17487/RFC5561, July 2009,
              <http://www.rfc-editor.org/info/rfc5561>.

Top      Up      ToC       Page 41 
   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, DOI 10.17487/RFC3471, January 2003,
              <http://www.rfc-editor.org/info/rfc3471>.

   [RFC3472]  Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized
              Multi-Protocol Label Switching (GMPLS) Signaling
              Constraint-based Routed Label Distribution Protocol (CR-
              LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, January
              2003, <http://www.rfc-editor.org/info/rfc3472>.

   [RFC6389]  Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
              Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389,
              November 2011, <http://www.rfc-editor.org/info/rfc6389>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <http://www.rfc-editor.org/info/rfc4090>.

   [RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
              IP Fast Reroute: Loop-Free Alternates", RFC 5286,
              DOI 10.17487/RFC5286, September 2008,
              <http://www.rfc-editor.org/info/rfc5286>.

   [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>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <http://www.rfc-editor.org/info/rfc3031>.

9.2.  Informative References

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <http://www.rfc-editor.org/info/rfc5920>.

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <http://www.rfc-editor.org/info/rfc3985>.

Top      Up      ToC       Page 42 
   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

   [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
              Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
              DOI 10.17487/RFC5659, October 2009,
              <http://www.rfc-editor.org/info/rfc5659>.

   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework",
              RFC 5714, DOI 10.17487/RFC5714, January 2010,
              <http://www.rfc-editor.org/info/rfc5714>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <http://www.rfc-editor.org/info/rfc5880>.

   [RFC5085]  Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual
              Circuit Connectivity Verification (VCCV): A Control
              Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085,
              December 2007, <http://www.rfc-editor.org/info/rfc5085>.

   [RFC5885]  Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
              Forwarding Detection (BFD) for the Pseudowire Virtual
              Circuit Connectivity Verification (VCCV)", RFC 5885,
              DOI 10.17487/RFC5885, June 2010,
              <http://www.rfc-editor.org/info/rfc5885>.

   [RFC7880]  Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
              Pallagatti, "Seamless Bidirectional Forwarding Detection
              (S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
              <http://www.rfc-editor.org/info/rfc7880>.

Top      Up      ToC       Page 43 
Acknowledgements

   This document leverages work done by Hannes Gredler, Yakov Rekhter,
   Minto Jeyananth, Kevin Wang, and several others on MPLS edge
   protection.  Thanks to Nischal Sheth and Bhupesh Kothari for their
   contributions.  Thanks to John E. Drake, Andrew G. Malis, Alexander
   Vainshtein, Stewart Bryant, and Mach(Guoyi) Chen for valuable
   comments that helped shape this document and improve its clarity.

Authors' Addresses

   Yimin Shen
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   United States of America

   Phone: +1 9785890722
   Email: yshen@juniper.net


   Rahul Aggarwal
   Arktan, Inc.

   Email: raggarwa_1@yahoo.com


   Wim Henderickx
   Nokia
   Copernicuslaan 50
   2018 Antwerp
   Belgium

   Email: wim.henderickx@nokia.com


   Yuanlong Jiang
   Huawei Technologies Co., Ltd.
   Bantian, Longgang district
   Shenzhen 518129
   China

   Email: jiangyuanlong@huawei.com