doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc8077.txt b/doc/rfc/rfc8077.txt
new file mode 100644
index 0000000..0f3c1e6
--- /dev/null
+++ b/doc/rfc/rfc8077.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                   L. Martini, Ed.
+Request for Comments: 8077                                 G. Heron, Ed.
+STD: 84                                                            Cisco
+Obsoletes: 4447, 6723                                      February 2017
+Category: Standards Track
+ISSN: 2070-1721
+
+
+                    Pseudowire Setup and Maintenance
+              Using the Label Distribution Protocol (LDP)
+
+Abstract
+
+   Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
+   and Ethernet) can be emulated over an MPLS backbone by encapsulating
+   the Layer 2 Protocol Data Units (PDUs) and then transmitting them
+   over pseudowires (PWs).  It is also possible to use pseudowires to
+   provide low-rate Time-Division Multiplexed and Synchronous Optical
+   NETworking circuit emulation over an MPLS-enabled network.  This
+   document specifies a protocol for establishing and maintaining the
+   pseudowires, using extensions to the Label Distribution Protocol
+   (LDP).  Procedures for encapsulating Layer 2 PDUs are specified in
+   other documents.
+
+   This document is a rewrite of RFC 4447 for publication as an Internet
+   Standard.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8077.
+
+
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                    [Page 1]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                    [Page 2]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Changes from RFC 4447 ...........................................6
+   3. Specification of Requirements ...................................6
+   4. The Pseudowire Label ............................................7
+   5. Details Specific to Particular Emulated Services ................9
+      5.1. IP Layer 2 Transport .......................................9
+   6. LDP .............................................................9
+      6.1. The PWid FEC Element .......................................9
+      6.2. The Generalized PWid FEC Element ..........................11
+           6.2.1. Attachment Identifiers .............................12
+           6.2.2. Encoding the Generalized PWid FEC Element ..........14
+                  6.2.2.1. PW Interface Parameters TLV ...............15
+                  6.2.2.2. PW Group ID TLV ...........................15
+           6.2.3. Signaling Procedures ...............................16
+      6.3. Signaling of Pseudowire Status ............................17
+           6.3.1. Use of Label Mapping Messages ......................17
+           6.3.2. Signaling PW Status ................................18
+           6.3.3. Pseudowire Status Negotiation Procedures ...........19
+      6.4. Interface Parameter Sub-TLV ...............................20
+      6.5. LDP Label Withdrawal Procedures ...........................21
+   7. Control Word ...................................................22
+      7.1. PW Types for Which the Control Word Is REQUIRED ...........22
+      7.2. PW Types for Which the Control Word Is NOT Mandatory ......22
+      7.3. Control-Word Renegotiation by Label Request Message .......24
+      7.4. Sequencing Considerations .................................25
+           7.4.1. Label Advertisements ...............................25
+           7.4.2. Label Release ......................................25
+   8. IANA Considerations ............................................26
+      8.1. LDP TLV TYPE ..............................................26
+      8.2. LDP Status Codes ..........................................26
+      8.3. FEC Type Name Space .......................................26
+   9. Security Considerations ........................................26
+      9.1. Data-Plane Security .......................................27
+      9.2. Control-Plane Security ....................................28
+   10. Interoperability and Deployment ...............................29
+   11. References ....................................................29
+      11.1. Normative References .....................................29
+      11.2. Informative References ...................................30
+   Acknowledgments ...................................................31
+   Contributors ......................................................32
+   Authors' Addresses ................................................35
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                    [Page 3]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+1.  Introduction
+
+   [RFC4619], [RFC4717], [RFC4618], and [RFC4448] explain how to
+   encapsulate a Layer 2 Protocol Data Unit (PDU) for transmission over
+   an MPLS-enabled network.  Those documents specify that a "pseudowire
+   header", consisting of a demultiplexer field, will be prepended to
+   the encapsulated PDU.  The pseudowire demultiplexer field is
+   prepended before transmitting a packet on a pseudowire.  When the
+   packet arrives at the remote endpoint of the pseudowire, the
+   demultiplexer is what enables the receiver to identify the particular
+   pseudowire on which the packet has arrived.  To transmit the packet
+   from one pseudowire endpoint to another, the packet may need to
+   travel through a "Packet Switched Network (PSN) tunnel"; this will
+   require that an additional header be prepended to the packet.
+
+   [RFC4842] and [RFC4553] specify two methods for transporting time-
+   division multiplexing (TDM) digital signals (TDM circuit emulation)
+   over a packet-oriented MPLS-enabled network.  The transmission system
+   for circuit-oriented TDM signals is the Synchronous Optical Network
+   (SONET) [ANSI] / Synchronous Digital Hierarchy (SDH) [ITUG].  To
+   support TDM traffic, which includes voice, data, and private leased-
+   line service, the pseudowires must emulate the circuit
+   characteristics of SONET/SDH payloads.  The TDM signals and payloads
+   are encapsulated for transmission over pseudowires.  A pseudowire
+   demultiplexer and a PSN tunnel header are prepended to this
+   encapsulation.
+
+   [RFC4553] describes methods for transporting low-rate time-division
+   multiplexing (TDM) digital signals (TDM circuit emulation) over PSNs,
+   while [RFC4842] similarly describes transport of high-rate TDM
+   (SONET/SDH).  To support TDM traffic, the pseudowires must emulate
+   the circuit characteristics of the original T1, E1, T3, E3, SONET, or
+   SDH signals.  [RFC4553] does this by encapsulating an arbitrary but
+   constant amount of the TDM data in each packet, and the other methods
+   encapsulate TDM structures.
+
+   In this document, we specify the use of the MPLS Label Distribution
+   Protocol (LDP) [RFC5036] as a protocol for setting up and maintaining
+   the pseudowires.  In particular, we define new TLVs, Forwarding
+   Equivalence Class (FEC) elements, parameters, and codes for LDP,
+   which enable LDP to identify pseudowires and to signal attributes of
+   pseudowires.  We specify how a pseudowire endpoint uses these TLVs in
+   LDP to bind a demultiplexer field value to a pseudowire and how it
+   informs the remote endpoint of the binding.  We also specify
+   procedures for reporting pseudowire status changes, for passing
+   additional information about the pseudowire as needed, and for
+   releasing the bindings.  These procedures are intended to be
+   independent of the underlying version of IP used for LDP signaling.
+
+
+
+Martini & Heron              Standards Track                    [Page 4]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   In the protocol specified herein, the pseudowire demultiplexer field
+   is an MPLS label.  Thus, the packets that are transmitted from one
+   end of the pseudowire to the other are MPLS packets, which must be
+   transmitted through an MPLS tunnel.  However, if the pseudowire
+   endpoints are immediately adjacent and penultimate hop popping
+   behavior is in use, the MPLS tunnel may not be necessary.  Any sort
+   of PSN tunnel can be used, as long as it is possible to transmit MPLS
+   packets through it.  The PSN tunnel can itself be an MPLS LSP, or any
+   other sort of tunnel that can carry MPLS packets.  Procedures for
+   setting up and maintaining the MPLS tunnels are outside the scope of
+   this document.
+
+   This document deals only with the setup and maintenance of point-to-
+   point pseudowires.  Neither point-to-multipoint nor multipoint-to-
+   point pseudowires are discussed.
+
+   QoS-related issues are not discussed in this document.
+
+   The following two figures describe the reference models that are
+   derived from [RFC3985] to support the PW emulated services.
+
+         |<-------------- Emulated Service ---------------->|
+         |                                                  |
+         |          |<------- Pseudowire ------->|          |
+         |          |                            |          |
+         |Attachment|    |<-- PSN Tunnel -->|    |Attachment|
+         |  Circuit V    V                  V    V  Circuit |
+         V   (AC)   +----+                  +----+   (AC)   V
+   +-----+    |     | PE1|==================| PE2|     |    +-----+
+   |     |----------|............PW1.............|----------|     |
+   | CE1 |    |     |    |                  |    |     |    | CE2 |
+   |     |----------|............PW2.............|----------|     |
+   +-----+  ^ |     |    |==================|    |     | ^  +-----+
+         ^  |       +----+                  +----+     | |  ^
+         |  |   Provider Edge 1         Provider Edge 2  |  |
+         |  |                                            |  |
+   Customer |                                            | Customer
+   Edge 1   |                                            | Edge 2
+            |                                            |
+      native service                               native service
+
+                     Figure 1: PWE3 Reference Model
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                    [Page 5]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+    +-----------------+                           +-----------------+
+    |Emulated Service |                           |Emulated Service |
+    |(e.g., TDM, ATM) |<==== Emulated Service ===>|(e.g., TDM, ATM) |
+    +-----------------+                           +-----------------+
+    |    Payload      |                           |    Payload      |
+    |  Encapsulation  |<====== Pseudowire =======>|  Encapsulation  |
+    +-----------------+                           +-----------------+
+    |PW Demultiplexer |                           |PW Demultiplexer |
+    |   PSN Tunnel,   |<======= PSN Tunnel ======>|  PSN Tunnel,    |
+    | PSN & Physical  |                           | PSN & Physical  |
+    |     Layers      |                           |    Layers       |
+    +-------+---------+        ___________        +---------+-------+
+            |                /             \                 |
+            +===============/     PSN       \================+
+                            \               /
+                             \_____________/
+
+              Figure 2: PWE3 Protocol Stack Reference Model
+
+   For the purpose of this document, PE1 (Provider Edge 1) will be
+   defined as the ingress router, and PE2 as the egress router.  A Layer
+   2 PDU will be received at PE1, encapsulated at PE1, transported and
+   decapsulated at PE2, and transmitted out of PE2.
+
+2.  Changes from RFC 4447
+
+   The changes in this document are mostly minor fixes to spelling and
+   grammar, or clarifications to the text, which were either noted as
+   errata to [RFC4447] or found by the editors.
+
+   Additionally, Section 7.3 ("Control-Word Renegotiation by Label
+   Request Message") has been added, obsoleting [RFC6723].  The diagram
+   of C-bit handling procedures has also been removed.  A note has been
+   added in Section 6.3.2 to clarify that the C-bit is part of the FEC.
+
+   A reference has also been added to [RFC7358] to indicate the use of
+   downstream unsolicited mode to distribute PW FEC label bindings,
+   independent of the negotiated label advertisement mode of the LDP
+   session.
+
+3.  Specification of Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+Martini & Heron              Standards Track                    [Page 6]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+4.  The Pseudowire Label
+
+   Suppose that it is desired to transport Layer 2 PDUs from ingress LSR
+   PE1 to egress LSR PE2, across an intervening MPLS-enabled network.
+   We assume that there is an MPLS tunnel from PE1 to PE2.  That is, we
+   assume that PE1 can cause a packet to be delivered to PE2 by
+   encapsulating the packet in an "MPLS tunnel header" and sending the
+   result to one of its adjacencies.  The MPLS tunnel is an MPLS Label
+   Switched Path (LSP); thus, putting on an MPLS tunnel encapsulation is
+   a matter of pushing on an MPLS label.
+
+   We presuppose that a large number of pseudowires can be carried
+   through a single MPLS tunnel.  Thus, it is never necessary to
+   maintain state in the network core for individual pseudowires.  We do
+   not presuppose that the MPLS tunnels are point to point; although the
+   pseudowires are point to point, the MPLS tunnels may be multipoint to
+   point.  We do not presuppose that PE2 will even be able to determine
+   the MPLS tunnel through which a received packet was transmitted.
+   (For example, if the MPLS tunnel is an LSP and penultimate hop
+   popping is used, when the packet arrives at PE2, it will contain no
+   information identifying the tunnel.)
+
+   When PE2 receives a packet over a pseudowire, it must be able to
+   determine that the packet was in fact received over a pseudowire, and
+   it must be able to associate that packet with a particular
+   pseudowire.  PE2 is able to do this by examining the MPLS label that
+   serves as the pseudowire demultiplexer field shown in Figure 2.  Call
+   this label the "PW label".
+
+   When PE1 sends a Layer 2 PDU to PE2, it creates an MPLS packet by
+   adding the PW label to the packet, thus creating the first entry of
+   the label stack.  If the PSN tunnel is an MPLS LSP, the PE1 pushes
+   another label (the tunnel label) onto the packet as the second entry
+   of the label stack.  The PW label is not visible again until the MPLS
+   packet reaches PE2.  PE2's disposition of the packet is based on the
+   PW label.
+
+   If the payload of the MPLS packet is, for example, an ATM Adaptation
+   Layer 5 (AAL5) PDU, the PW label will generally correspond to a
+   particular ATM Virtual Circuit (VC) at PE2.  That is, PE2 needs to be
+   able to infer from the PW label the outgoing interface and the
+   VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) value
+   for the AAL5 PDU.  If the payload is a Frame Relay PDU, then PE2
+   needs to be able to infer from the PW label the outgoing interface
+   and the Data Link Connection Identifier (DLCI) value.  If the payload
+   is an Ethernet frame, then PE2 needs to be able to infer from the PW
+   label the outgoing interface, and perhaps the VLAN identifier.  This
+   process is unidirectional and will be repeated independently for
+
+
+
+Martini & Heron              Standards Track                    [Page 7]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   bidirectional operation.  When using the PWid FEC Element, it is
+   REQUIRED that the same PW ID and PW type be assigned for a given
+   circuit in both directions.  The Group ID (see below) MUST NOT be
+   required to match in both directions.  The transported frame MAY be
+   modified when it reaches the egress router.  If the header of the
+   transported Layer 2 frame is modified, this MUST be done at the
+   egress LSR only.  Note that the PW label must always be at the bottom
+   of the packet's label stack, and labels MUST be allocated from the
+   per-platform label space.
+
+   This document does not specify a method for distributing the MPLS
+   tunnel label or any other labels that may appear above the PW label
+   on the stack.  Any acceptable method of MPLS label distribution will
+   do.  This document specifies a protocol for assigning and
+   distributing the PW label.  This protocol is LDP, extended as
+   specified in the remainder of this document.  An LDP session must be
+   set up between the pseudowire endpoints.  LDP MUST exchange PW FEC
+   label bindings in downstream unsolicited mode, independent of the
+   negotiated label advertisement mode of the LDP session according to
+   the specifications in [RFC7358].  LDP's "liberal label retention"
+   mode SHOULD be used.  However, all the LDP procedures that are
+   specified in [RFC5036] and that are also applicable to this protocol
+   specification MUST be implemented.
+
+   This document requires that a receiving LSR MUST respond to a Label
+   Request message with either a Label Mapping for the requested label
+   or a Notification message that indicates why it cannot satisfy the
+   request.  These procedures are specified in [RFC5036], Sections 3.5.7
+   ("Label Mapping Message") and 3.5.8 ("Label Request Message").  Note
+   that sending these responses is a stricter requirement than is
+   specified in [RFC5036], but these response messages are REQUIRED to
+   ensure correct operation of this protocol.
+
+   In addition to the protocol specified herein, static assignment of PW
+   labels may be used, and implementations of this protocol SHOULD
+   provide support for static assignment.  PW encapsulation is always
+   symmetrical in both directions of traffic along a specific PW,
+   whether or not the PW uses an LDP control plane.
+
+   This document specifies all the procedures necessary to set up and
+   maintain the pseudowires needed to support "unswitched" point-to-
+   point services, where each endpoint of the pseudowire is provisioned
+   with the identity of the other endpoint.  There are also protocol
+   mechanisms specified herein that can be used to support switched
+   services and other provisioning models.  However, the use of the
+   protocol mechanisms to support those other models and services is not
+   described in this document.
+
+
+
+
+Martini & Heron              Standards Track                    [Page 8]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+5.  Details Specific to Particular Emulated Services
+
+5.1.  IP Layer 2 Transport
+
+   This mode carries IP packets over a pseudowire.  The encapsulation
+   used is according to [RFC3032].  The PW control word MAY be inserted
+   between the MPLS label stack and the IP payload.  The encapsulation
+   of the IP packets for forwarding on the Attachment Circuit is
+   implementation specific, is part of the native service processing
+   (NSP) function [RFC3985], and is outside the scope of this document.
+
+6.  LDP
+
+   The PW label bindings are distributed using the LDP downstream
+   unsolicited mode described in [RFC5036].  The PEs will establish an
+   LDP session using the Extended Discovery mechanism described in
+   Sections 2.4.2 and 2.5 of [RFC5036].
+
+   An LDP Label Mapping message contains a FEC TLV, a Label TLV, and
+   zero or more optional parameter TLVs.
+
+   The FEC TLV is used to indicate the meaning of the label.  In the
+   current context, the FEC TLV would be used to identify the particular
+   pseudowire that a particular label is bound to.  In this
+   specification, we define two new FEC TLVs to be used for identifying
+   pseudowires.  When setting up a particular pseudowire, only one of
+   these FEC TLVs is used.  The one to be used will depend on the
+   particular service being emulated and on the particular provisioning
+   model being supported.
+
+   LDP allows each FEC TLV to consist of a set of FEC elements.  For
+   setting up and maintaining pseudowires, however, each FEC TLV MUST
+   contain exactly one FEC element.
+
+   The LDP base specification has several kinds of label TLVs, including
+   the Generic Label TLV, as specified in Section 3.4.2.1 of [RFC5036].
+   For setting up and maintaining pseudowires, the Generic Label TLV
+   MUST be used.
+
+6.1.  The PWid FEC Element
+
+   The PWid FEC Element may be used whenever both pseudowire endpoints
+   have been provisioned with the same 32-bit identifier for the
+   pseudowire.
+
+   For this purpose, a new type of FEC element is defined.  The FEC
+   element type is 0x80 and is defined as follows:
+
+
+
+
+Martini & Heron              Standards Track                    [Page 9]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  PWid (0x80)  |C|         PW type             |PW info length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Group ID                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           PW ID                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                Interface Parameter Sub-TLV                    |
+   |                              "                                |
+   |                              "                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   -  Control word bit (C)
+
+      The C-bit is used to flag the presence of a control word as
+      follows:
+
+         C = 1 control word present on this PW.
+         C = 0 no control word present on this PW.
+
+      Please see Section 7 ("Control Word") for further explanation.
+
+   -  PW type
+
+      A 15-bit quantity containing a value that represents the type of
+      PW.  Assigned Values are specified in "IANA Allocations for
+      Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].
+
+   -  PW info length
+
+      Length of the PW ID field and the Interface Parameter Sub-TLV
+      field in octets.  If this value is 0, then it references all PWs
+      using the specified Group ID, and there is no PW ID present, nor
+      are there any Interface Parameter Sub-TLVs.
+
+   -  Group ID
+
+      An arbitrary 32-bit value that represents a group of PWs that is
+      used to create groups in the PW space.  The Group ID is intended
+      to be used as a port index or a virtual tunnel index.  To simplify
+      configuration, a particular PW Group ID at ingress could be part
+      of a Group ID assigned to the virtual tunnel for transport to the
+      egress router.  The Group ID is very useful for sending wildcard
+      label withdrawals or PW wildcard status Notification messages to
+      remote PEs upon physical port failure.
+
+
+
+
+Martini & Heron              Standards Track                   [Page 10]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   -  PW ID
+
+      A non-zero, 32-bit connection ID that together with the PW type
+      identifies a particular PW.  Note that the PW ID and the PW type
+      MUST be the same at both endpoints.
+
+   -  Interface Parameter Sub-TLV
+
+      This variable length TLV is used to provide interface-specific
+      parameters, such as Attachment Circuit MTU.
+
+      Note that as the Interface Parameter Sub-TLV is part of the FEC,
+      the rules of LDP make it impossible to change the interface
+      parameters once the pseudowire has been set up.  Thus, the
+      interface parameters field must not be used to pass information,
+      such as status information, that may change during the life of the
+      pseudowire.  Optional parameter TLVs should be used for that
+      purpose.
+
+   Using the PWid FEC, each of the two pseudowire endpoints
+   independently initiates the setup of a unidirectional LSP.  An
+   outgoing LSP and an incoming LSP are bound together into a single
+   pseudowire if they have the same PW ID and PW type.
+
+6.2.  The Generalized PWid FEC Element
+
+   The PWid FEC Element can be used if a unique 32-bit value has been
+   assigned to the PW and if each endpoint has been provisioned with
+   that value.  The Generalized PWid FEC Element requires that the PW
+   endpoints be uniquely identified; the PW itself is identified as a
+   pair of endpoints.  In addition, the endpoint identifiers are
+   structured to support applications where the identity of the remote
+   endpoints needs to be auto-discovered rather than statically
+   configured.
+
+   The "Generalized PWid FEC Element" is FEC type 0x81.
+
+   The Generalized PWid FEC Element does not contain anything
+   corresponding to the Group ID of the PWid FEC Element.  The
+   functionality of the Group ID is provided by a separate optional LDP
+   TLV, the PW Group ID TLV, described in Section 6.2.2.2.  The
+   interface parameters field of the PWid FEC Element is also absent;
+   its functionality is replaced by the optional PW Interface Parameters
+   TLV, described in Section 6.2.2.1.
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 11]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+6.2.1.  Attachment Identifiers
+
+   As discussed in [RFC3985], a pseudowire can be thought of as
+   connecting two "forwarders".  The protocol used to set up a
+   pseudowire must allow the forwarder at one end of a pseudowire to
+   identify the forwarder at the other end.  We use the term "Attachment
+   Identifier", or "AI", to refer to the field that the protocol uses to
+   identify the forwarders.  In the PWid FEC, the PWid field serves as
+   the AI.  In this section, we specify a more general form of AI that
+   is structured and of variable length.
+
+   Every Forwarder in a PE must be associated with an Attachment
+   Identifier (AI), either through configuration or through some
+   algorithm.  The Attachment Identifier must be unique in the context
+   of the PE router in which the Forwarder resides.  The combination <PE
+   router IP address, AI> must be globally unique.
+
+   It is frequently convenient to regard a set of Forwarders as being
+   members of a particular "group", where PWs may only be set up among
+   members of a group.  In such cases, it is convenient to identify the
+   Forwarders relative to the group, so that an Attachment Identifier
+   would consist of an Attachment Group Identifier (AGI) plus an
+   Attachment Individual Identifier (AII).
+
+   An Attachment Group Identifier may be thought of as a VPN-id, or a
+   VLAN identifier, some attribute that is shared by all the Attachment
+   PWs (or pools thereof) that are allowed to be connected.
+
+   The details of how to construct the AGI and AII fields identifying
+   the pseudowire endpoints are outside the scope of this specification.
+   Different pseudowire applications, and different provisioning models,
+   will require different sorts of AGI and AII fields.  The
+   specification of each such application and/or model must include the
+   rules for constructing the AGI and AII fields.
+
+   As previously discussed, a (bidirectional) pseudowire consists of a
+   pair of unidirectional LSPs, one in each direction.  If a particular
+   pseudowire connects PE1 with PE2, the PW direction from PE1 to PE2
+   can be identified as:
+
+      <PE1, <AGI, AII1>, PE2, <AGI, AII2>>,
+
+   and the PW direction from PE2 to PE1 can be identified by:
+
+      <PE2, <AGI, AII2>, PE1, <AGI, AII1>>.
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 12]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   Note that the AGI must be the same at both endpoints, but the AII
+   will in general be different at each endpoint.  Thus, from the
+   perspective of a particular PE, each pseudowire has a local or
+   "Source AII", and a remote or "Target AII".  The pseudowire setup
+   protocol can carry all three of these quantities:
+
+   -  Attachment Group Identifier (AGI)
+
+   -  Source Attachment Individual Identifier (SAII)
+
+   -  Target Attachment Individual Identifier (TAII)
+
+   If the AGI is non-null, then the Source AI (SAI) consists of the AGI
+   together with the SAII, and the Target AI (TAI) consists of the TAII
+   together with the AGI.  If the AGI is null, then the SAII and TAII
+   are the SAI and TAI, respectively.
+
+   The interpretation of the SAI and TAI is a local matter at the
+   respective endpoint.
+
+   The association of two unidirectional LSPs into a single
+   bidirectional pseudowire depends on the SAI and the TAI.  Each
+   application and/or provisioning model that uses the Generalized PWid
+   FEC must specify the rules for performing this association.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 13]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+6.2.2.  Encoding the Generalized PWid FEC Element
+
+   FEC element type 0x81 is used.  The FEC element is encoded as
+   follows:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |Gen PWid (0x81)|C|         PW Type             |PW info length |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   AGI Type    |    Length     |      Value                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                    AGI  Value (contd.)                        ~
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   AII Type    |    Length     |      Value                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                   SAII  Value (contd.)                        ~
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   AII Type    |    Length     |      Value                    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                   TAII Value (contd.)                         ~
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   This document does not specify the AII and AGI type field values;
+   specification of the type field values to be used for a particular
+   application is part of the specification of that application.  IANA
+   has assigned these values using the method defined in [RFC4446].
+
+   The SAII, TAII, and AGI are simply carried as octet strings.  The
+   Length byte specifies the size of the Value field.  The null string
+   can be sent by setting the Length byte to 0.  If a particular
+   application does not need all three of these sub-elements, it MUST
+   send all the sub-elements but set the Length to 0 for the unused sub-
+   elements.
+
+   The PW information length field contains the length of the SAII,
+   TAII, and AGI, combined in octets.  If this value is 0, then it
+   references all PWs using the specific Group ID (specified in the PW
+   Group ID TLV).  In this case, there are no other FEC element fields
+   (AGI, SAII, etc.) present, nor any PW Interface Parameters TLVs.
+
+   Note that the interpretation of a particular field as AGI, SAII, or
+   TAII depends on the order of its occurrence.  The Type field
+   identifies the type of the AGI, SAII, or TAII.  When comparing two
+
+
+
+
+Martini & Heron              Standards Track                   [Page 14]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   occurrences of an AGI (or SAII or TAII), the two occurrences are
+   considered identical if the Type, Length, and Value fields of one are
+   identical, respectively, to those of the other.
+
+6.2.2.1.  PW Interface Parameters TLV
+
+   This TLV MUST only be used when sending the Generalized PWid FEC.  It
+   specifies interface-specific parameters.  Specific parameters, when
+   applicable, MUST be used to validate that the PEs and the ingress and
+   egress ports at the edges of the circuit have the necessary
+   capabilities to interoperate with each other.
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |0|0|  PW Intf P. TLV (0x096B)  |            Length             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Sub-TLV Type  |    Length     |    Variable Length Value      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         Variable Length Value                 |
+    |                             "                                 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   A more detailed description of this field can be found in Section 6.4
+   ("Interface Parameter Sub-TLV").
+
+6.2.2.2.  PW Group ID 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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |0|0| PW Group ID TLV (0x096C)  |            Length             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                             Value                             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The PW Group ID is an arbitrary 32-bit value that represents an
+   arbitrary group of PWs.  It is used to create group PWs; for example,
+   a PW Group ID can be used as a port index and assigned to all PWs
+   that lead to that port.  Use of the PW Group ID enables a PE to send
+   "wildcard" label withdrawals, or "wildcard" status Notification
+   messages, to remote PEs upon physical port failure.
+
+   Note Well: The PW Group ID is different from and has no relation to
+   the Attachment Group Identifier.
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 15]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   The PW Group ID TLV is not part of the FEC and will not be advertised
+   except in the PW FEC advertisement.  The advertising PE MAY use the
+   wildcard withdraw semantics, but the remote PEs MUST implement
+   support for wildcard messages.  This TLV MUST only be used when
+   sending the Generalized PWid FEC.
+
+   To issue a wildcard command (status or withdraw):
+
+   -  Set the PW Info Length to 0 in the Generalized PWid FEC Element.
+
+   -  Send only the PW Group ID TLV with the FEC (no AGI/SAII/TAII is
+      sent).
+
+6.2.3.  Signaling Procedures
+
+   In order for PE1 to begin signaling PE2, PE1 must know the address of
+   the remote PE2 and a TAI.  This information may have been configured
+   at PE1, or it may have been learned dynamically via some auto-
+   discovery procedure.
+
+   The egress PE (PE1), which has knowledge of the ingress PE, initiates
+   the setup by sending a Label Mapping message to the ingress PE (PE2).
+   The Label Mapping message contains the FEC TLV, carrying the
+   Generalized PWid FEC Element (type 0x81).  The Generalized PWid FEC
+   Element contains the AGI, SAII, and TAII information.
+
+   Next, when PE2 receives such a Label Mapping message, PE2 interprets
+   the message as a request to set up a PW whose endpoint (at PE2) is
+   the Forwarder identified by the TAI.  From the perspective of the
+   signaling protocol, exactly how PE2 maps AIs to Forwarders is a local
+   matter.  In some Virtual Private Wire Service (VPWS) provisioning
+   models, the TAI might, for example, be a string that identifies a
+   particular Attachment Circuit, such as "ATM3VPI4VCI5", or it might,
+   for example, be a string, such as "Fred", that is associated by
+   configuration with a particular Attachment Circuit.  In Virtual
+   Private LAN Service (VPLS), the AGI could be a VPN-id, identifying a
+   particular VPLS instance.
+
+   If PE2 cannot map the TAI to one of its Forwarders, then PE2 sends a
+   Label Release message to PE1, with a Status Code of
+   "Unassigned/Unrecognized TAI", and the processing of the Label
+   Mapping message is complete.
+
+   The FEC TLV sent in a Label Release message is the same as the FEC
+   TLV received in the Label Mapping message being released (but without
+   the interface parameter TLV).  More generally, the FEC TLV is the
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 16]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   same in all LDP messages relating to the same PW.  In a Label Release
+   message, this means that the SAII is the remote peer's AII and the
+   TAII is the sender's local AII.
+
+   If the Label Mapping message has a valid TAI, PE2 must decide whether
+   to accept it.  The procedures for so deciding will depend on the
+   particular type of Forwarder identified by the TAI.  Of course, the
+   Label Mapping message may be rejected due to standard LDP error
+   conditions as detailed in [RFC5036].
+
+   If PE2 decides to accept the Label Mapping message, then it has to
+   make sure that a PW LSP is set up in the opposite (PE1-->PE2)
+   direction.  If it has already signaled for the corresponding PW LSP
+   in that direction, nothing more needs to be done.  Otherwise, it must
+   initiate such signaling by sending a Label Mapping message to PE1.
+   This is very similar to the Label Mapping message PE2 received, but
+   the SAI and TAI are reversed.
+
+   Thus, a bidirectional PW consists of two LSPs, where the FEC of one
+   has the SAII and TAII reversed with respect to the FEC of the other.
+
+6.3.  Signaling of Pseudowire Status
+
+6.3.1.  Use of Label Mapping Messages
+
+   The PEs MUST send Label Mapping messages to their peers as soon as
+   the PW is configured and administratively enabled, regardless of the
+   Attachment Circuit state.  The PW label should not be withdrawn
+   unless the operator administratively configures the pseudowire down
+   (or the PW configuration is deleted entirely).  Using the procedures
+   outlined in this section, a simple label withdraw method MAY also be
+   supported as a legacy means of signaling PW status and AC status.  In
+   any case, if the label-to-PW binding is not available, the PW MUST be
+   considered in the down state.
+
+   Once the PW status negotiation procedures are completed, if they
+   result in the use of the label withdraw method for PW status
+   communication, and this method is not supported by one of the PEs,
+   then that PE must send a Label Release message to its peer with the
+   following error:
+
+   "Label Withdraw PW Status Method Not Supported"
+
+   If the label withdraw method for PW status communication is selected
+   for the PW, it will result in the Label Mapping message being
+   advertised only if the Attachment Circuit is active.  The PW status
+   signaling procedures described in this section MUST be fully
+   implemented.
+
+
+
+Martini & Heron              Standards Track                   [Page 17]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+6.3.2.  Signaling PW Status
+
+   The PE devices use an LDP TLV to indicate status to their remote
+   peers.  This PW Status TLV contains more information than the
+   alternative simple Label Withdraw message.
+
+   The format of the PW Status TLV is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |1|0|     PW Status (0x096A)    |            Length             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         Status Code                           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The status code is a 4-octet bit field as specified in "IANA
+   Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].
+   The Length field specifies the length of the Status Code field in
+   octets (equal to 4).
+
+   Each bit in the Status Code field can be set individually to indicate
+   more than a single failure at once.  Each fault can be cleared by
+   sending an appropriate Notification message in which the respective
+   bit is cleared.  The presence of the lowest bit (PW Not Forwarding)
+   acts only as a generic failure indication when there is a link-down
+   event for which none of the other bits apply.
+
+   The Status TLV is transported to the remote PW peer via the LDP
+   Notification message as described in [RFC5036].  The format of the
+   Notification message for carrying the PW Status is as follows:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |0|   Notification (0x0001)     |      Message Length           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Message ID                              |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Status (TLV)                            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      PW Status TLV                            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |           PWid FEC TLV or Generalized ID FEC TLV              |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                PW Group ID TLV (Optional)                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 18]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   The Status TLV status code is set to 0x00000028, "PW status", to
+   indicate that PW status follows.  Since this notification does not
+   refer to any particular message, the Message ID field is set to 0.
+
+   The PW FEC TLV SHOULD NOT include the Interface Parameter Sub-TLVs,
+   as they are ignored in the context of this message.  However, the PW
+   FEC TLV MUST include the C-bit, where applicable, as it is part of
+   the FEC.  When a PE's Attachment Circuit encounters an error, use of
+   the PW Notification message allows the PE to send a single "wildcard"
+   status message, using a PW FEC TLV with only the Group ID set, to
+   denote this change in status for all affected PW connections.  This
+   status message contains either the PW FEC TLV with only the Group ID
+   set, or else it contains the Generalized FEC TLV with only the PW
+   Group ID TLV.
+
+   As mentioned above, the Group ID field of the PWid FEC Element, or
+   the PW Group ID TLV used with the Generalized PWid FEC Element, can
+   be used to send a status notification for all arbitrary sets of PWs.
+   This procedure is OPTIONAL, and if it is implemented, the LDP
+   Notification message should be as follows: If the PWid FEC Element is
+   used, the PW information length field is set to 0, the PW ID field is
+   not present, and the Interface Parameter Sub-TLVs are not present.
+   If the Generalized FEC Element is used, the AGI, SAII, and TAII are
+   not present, the PW information length field is set to 0, the PW
+   Group ID TLV is included, and the PW Interface Parameters TLV is
+   omitted.  For the purpose of this document, this is called the
+   "wildcard PW status notification procedure", and all PEs implementing
+   this design are REQUIRED to accept such a Notification message but
+   are not required to send it.
+
+6.3.3.  Pseudowire Status Negotiation Procedures
+
+   When a PW is first set up, the PEs MUST attempt to negotiate the
+   usage of the PW Status TLV.  This is accomplished as follows: A PE
+   that supports the PW Status TLV MUST include it in the initial Label
+   Mapping message following the PW FEC and the Interface Parameter Sub-
+   TLVs.  The PW Status TLV will then be used for the lifetime of the
+   pseudowire.  This is shown in the following diagram:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 19]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    +                 PWid FEC or Generalized PWid FEC              +
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                       Interface Parameters                    |
+    |                              "                                |
+    |                              "                                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |0|0| Generic Label (0x0200)    |      Length                   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     Label                                                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |1|0|     PW Status (0x096A)    |            Length             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         Status Code                           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   If a PW Status TLV is included in the initial Label Mapping message
+   for a PW, then if the Label Mapping message from the remote PE for
+   that PW does not include a PW Status TLV, or if the remote PE does
+   not support the PW Status TLV, the PW will revert to the label
+   withdraw method of signaling PW status.  Note that if the PW Status
+   TLV is not supported by the remote peer, the peer will automatically
+   ignore it, since the I (ignore) bit is set in the TLV.  The PW Status
+   TLV, therefore, will not be present in the corresponding FEC
+   advertisement from the remote LDP peer, which results in exactly the
+   above behavior.
+
+   If the PW Status TLV is not present following the FEC TLV in the
+   initial PW Label Mapping message received by a PE, then the PW Status
+   TLV will not be used, and both PEs supporting the pseudowire will
+   revert to the label withdraw procedure for signaling status changes.
+
+   If the negotiation process results in the usage of the PW Status TLV,
+   then the actual PW status is determined by the PW Status TLV that was
+   sent within the initial PW Label Mapping message.  Subsequent updates
+   of PW status are conveyed through the Notification message.
+
+6.4.  Interface Parameter Sub-TLV
+
+   This field specifies interface-specific parameters.  When applicable,
+   it MUST be used to validate that the PEs and the ingress and egress
+   ports at the edges of the circuit have the necessary capabilities to
+   interoperate with each other.  The field structure is defined as
+   follows:
+
+
+
+Martini & Heron              Standards Track                   [Page 20]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | Sub-TLV Type  |    Length     |    Variable Length Value      |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         Variable Length Value                 |
+    |                             "                                 |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Length field is defined as the length of the interface parameter
+   including the Sub-TLV Type and Length field itself.  Processing of
+   the interface parameters should continue when unknown interface
+   parameters are encountered, and they MUST be silently ignored.
+
+   The Interface Parameter Sub-TLV Type values are specified in "IANA
+   Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [RFC4446].
+
+   -  Interface MTU sub-TLV type
+
+      A 2-octet value indicating the MTU in octets.  This is the Maximum
+      Transmission Unit, excluding encapsulation overhead, of the egress
+      packet interface that will be transmitting the decapsulated PDU
+      that is received from the MPLS-enabled network.  This parameter is
+      applicable only to PWs transporting packets and is REQUIRED for
+      these PW types.  If this parameter does not match in both
+      directions of a specific PW, that PW MUST NOT be enabled.
+
+   -  Optional Interface Description string sub-TLV type
+
+      This arbitrary, and OPTIONAL, interface description string is used
+      to send a human-readable administrative string describing the
+      interface to the remote PE.  This parameter is OPTIONAL and is
+      applicable to all PW types.  The interface description parameter
+      string length is variable and can be from 0 to 80 octets.  Human-
+      readable text MUST be provided in the UTF-8 charset using the
+      Default Language [RFC2277].
+
+6.5.  LDP Label Withdrawal Procedures
+
+   As mentioned above, the Group ID field of the PWid FEC Element, or
+   the PW Group ID TLV used with the Generalized PWid FEC Element, can
+   be used to withdraw all PW labels associated with a particular PW
+   group.  This procedure is OPTIONAL, and if it is implemented, the LDP
+   Label Withdraw message should be as follows: If the PWid FEC Element
+   is used, the PW information length field is set to 0, the PW ID field
+   is not present, the Interface Parameter Sub-TLVs are not present, and
+   the Label TLV is not present.  If the Generalized FEC Element is
+   used, the AGI, SAII, and TAII are not present, the PW information
+
+
+
+Martini & Heron              Standards Track                   [Page 21]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   length field is set to 0, the PW Group ID TLV is included, the PW
+   Interface Parameters TLV is not present, and the Label TLV is not
+   present.  For the purpose of this document, this is called the
+   "wildcard withdraw procedure", and all PEs implementing this design
+   are REQUIRED to accept such withdraw messages but are not required to
+   send it.  Note that the PW Group ID TLV only applies to PWs using the
+   Generalized ID FEC Element, while the Group ID only applies to PWid
+   FEC Element.
+
+   The Interface Parameter Sub-TLVs, or TLV, MUST NOT be present in any
+   LDP PW Label Withdraw or Label Release message.  A wildcard Label
+   Release message MUST include only the Group ID or PW Group ID TLV.  A
+   Label Release message initiated by a PE router must always include
+   the PW ID.
+
+7.  Control Word
+
+7.1.  PW Types for Which the Control Word Is REQUIRED
+
+   The Label Mapping messages that are sent in order to set up these PWs
+   MUST have C=1.  When a Label Mapping message for a PW of one of these
+   types is received and C=0, a Label Release message MUST be sent, with
+   an "Illegal C-bit" status code.  In this case, the PW will not be
+   enabled.
+
+7.2.  PW Types for Which the Control Word Is NOT Mandatory
+
+   If a system is capable of sending and receiving the control word on
+   PW types for which the control word is not mandatory, then each such
+   PW endpoint MUST be configurable with a parameter that specifies
+   whether the use of the control word is PREFERRED or NOT PREFERRED.
+   For each PW, there MUST be a default value of this parameter.  This
+   specification does NOT state what the default value should be.
+
+   If a system is NOT capable of sending and receiving the control word
+   on PW types for which the control word is not mandatory, then it
+   behaves exactly as if it were configured for the use of the control
+   word to be NOT PREFERRED.
+
+   If a Label Mapping message for the PW has already been received but
+   no Label Mapping message for the PW has yet been sent, then the
+   procedure is as follows:
+
+        -i. If the received Label Mapping message has C=0, send a Label
+            Mapping message with C=0; the control word is not used.
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 22]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+       -ii. If the received Label Mapping message has C=1, and the PW is
+            locally configured such that the use of the control word is
+            preferred, then send a Label Mapping message with C=1; the
+            control word is used.
+
+      -iii. If the received Label Mapping message has C=1, and the PW is
+            locally configured such that the use of the control word is
+            not preferred or the control word is not supported, then act
+            as if no Label Mapping message for the PW had been received
+            (i.e., proceed to the next paragraph).
+
+   If a Label Mapping message for the PW has not already been received
+   (or if the received Label Mapping message had C=1 and either local
+   configuration says that the use of the control word is not preferred
+   or the control word is not supported), then send a Label Mapping
+   message in which the C-bit is set to correspond to the locally
+   configured preference for use of the control word.  (That is, set C=1
+   if locally configured to prefer the control word, and set C=0 if
+   locally configured to prefer not to use the control word or if the
+   control word is not supported).
+
+   The next action depends on what control message is next received for
+   that PW.  The possibilities are as follows:
+
+        -i. A Label Mapping message with the same C-bit value as
+            specified in the Label Mapping message that was sent.  PW
+            setup is now complete, and the control word is used if C=1
+            but is not used if C=0.
+
+       -ii. A Label Mapping message with C=1, but the Label Mapping
+            message that was sent has C=0.  In this case, ignore the
+            received Label Mapping message and continue to wait for the
+            next control message for the PW.
+
+      -iii. A Label Mapping message with C=0, but the Label Mapping
+            message that was sent has C=1.  In this case, send a Label
+            Withdraw message with a "Wrong C-bit" status code, followed
+            by a Label Mapping message that has C=0.  PW setup is now
+            complete, and the control word is not used.
+
+       -iv. A Label Withdraw message with the "Wrong C-bit" status code.
+            Treat as a normal Label Withdraw message, but do not
+            respond.  Continue to wait for the next control message for
+            the PW.
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 23]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   If at any time after a Label Mapping message has been received a
+   corresponding Label Withdraw or Release is received, the action taken
+   is the same as for any Label Withdraw or Release messages that might
+   be received at any time.
+
+   If both endpoints prefer the use of the control word, this procedure
+   will cause it to be used.  If either endpoint prefers not to use the
+   control word or does not support the control word, this procedure
+   will cause it not to be used.  If one endpoint prefers to use the
+   control word but the other does not, the one that prefers not to use
+   it has no extra protocol to execute; it just waits for a Label
+   Mapping message that has C=0.
+
+7.3.  Control-Word Renegotiation by Label Request Message
+
+   It is possible that after the PW C-bit negotiation procedure
+   described above is complete, the local PE is re-provisioned with a
+   different control word preference.  Therefore, once the control-word
+   negotiation procedures are complete, the procedure can be restarted
+   as follows:
+
+        -i. If the local PE previously sent a Label Mapping message, it
+            MUST send a Label Withdraw message to the remote PE and wait
+            until it has received a Label Release message from the
+            remote PE.
+
+       -ii. The local PE MUST send a Label Release message to the remote
+            PE for the specific label associated with the FEC that was
+            advertised for this specific PW.  Note: The above-mentioned
+            steps of the Label Release message and Label Withdraw
+            message are not required to be executed in any specific
+            sequence.
+
+      -iii. The local PE MUST send a Label Request message to the peer
+            PE and then MUST wait until it receives a Label Mapping
+            message containing the remote PE's currently configured
+            preference for use of the control word.
+
+   Once the remote PE has successfully processed the Label Withdraw
+   message and Label Release messages, it will reset the C-bit
+   negotiation state machine and its use of the control word with the
+   locally configured preference.
+
+   From this point on, the local and remote PEs will follow the C-bit
+   negotiation procedures defined in the previous section.
+
+   The above C-bit renegotiation process SHOULD NOT be interrupted until
+   it is completed, or unpredictable results might occur.
+
+
+
+Martini & Heron              Standards Track                   [Page 24]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+7.4.  Sequencing Considerations
+
+   In the case where the router considers the sequence number field in
+   the control word, it is important to note the following details when
+   advertising labels.
+
+7.4.1.  Label Advertisements
+
+   After a label has been withdrawn by the output router and/or released
+   by the input router, care must be taken not to advertise (reuse) the
+   same released label until the output router can be reasonably certain
+   that old packets containing the released label no longer persist in
+   the MPLS-enabled network.
+
+   This precaution is required to prevent the imposition router from
+   restarting packet forwarding with a sequence number of 1 when it
+   receives a Label Mapping message that binds the same FEC to the same
+   label if there are still older packets in the network with a sequence
+   number between 1 and 32768.  For example, if there is a packet with
+   sequence number=n, where n is in the interval [1,32768] traveling
+   through the network, it would be possible for the disposition router
+   to receive that packet after it re-advertises the label.  Since the
+   label has been released by the imposition router, the disposition
+   router SHOULD be expecting the next packet to arrive with a sequence
+   number of 1.  Receipt of a packet with a sequence number equal to n
+   will result in n packets potentially being rejected by the
+   disposition router until the imposition router imposes a sequence
+   number of n+1 into a packet.  Possible methods to avoid this are for
+   the disposition router always to advertise a different PW label, or
+   for the disposition router to wait for a sufficient time before
+   attempting to re-advertise a recently released label.  This is only
+   an issue when sequence number processing is enabled at the
+   disposition router.
+
+7.4.2.  Label Release
+
+   In situations where the imposition router wants to restart forwarding
+   of packets with sequence number 1, the router shall 1) send to the
+   disposition router a Label Release message, and 2) send to the
+   disposition router a Label Request message.  When sequencing is
+   supported, advertisement of a PW label in response to a Label Request
+   message MUST also consider the issues discussed in Section 7.4.1
+   ("Label Advertisements").
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 25]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+8.  IANA Considerations
+
+8.1.  LDP TLV TYPE
+
+   This document uses several new LDP TLV types; IANA already maintains
+   a registry titled "TLV Type Name Space", defined by RFC 5036.  The
+   following values have been assigned from said registry:
+
+     TLV Type  Description
+     =====================================
+     0x096A    PW Status TLV
+     0x096B    PW Interface Parameters TLV
+     0x096C    PW Group ID TLV
+
+8.2.  LDP Status Codes
+
+   This document uses several new LDP status codes; IANA already
+   maintains a registry titled "Status Code Name Space", defined by RFC
+   5036.  The following values have been assigned:
+
+     Range/Value     E     Description                       Reference
+     ------------- -----   ----------------------            ---------
+     0x00000024      0     Illegal C-Bit                     [RFC8077]
+     0x00000025      0     Wrong C-Bit                       [RFC8077]
+     0x00000026      0     Incompatible bit-rate             [RFC8077]
+     0x00000027      0     CEP-TDM mis-configuration         [RFC8077]
+     0x00000028      0     PW Status                         [RFC8077]
+     0x00000029      0     Unassigned/Unrecognized TAI       [RFC8077]
+     0x0000002A      0     Generic Misconfiguration Error    [RFC8077]
+     0x0000002B      0     Label Withdraw PW Status          [RFC8077]
+                           Method Not Supported
+
+8.3.  FEC Type Name Space
+
+   This document uses two new FEC element types, 0x80 and 0x81, from the
+   registry "Forwarding Equivalence Class (FEC) Type Name Space" for the
+   Label Distribution Protocol (LDP) [RFC5036].
+
+9.  Security Considerations
+
+   This document specifies the LDP extensions that are needed for
+   setting up and maintaining pseudowires.  The purpose of setting up
+   pseudowires is to enable Layer 2 frames to be encapsulated in MPLS
+   and transmitted from one end of a pseudowire to the other.
+   Therefore, we address the security considerations for both the data
+   plane and the control plane.
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 26]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+9.1.  Data-Plane Security
+
+   With regard to the security of the data plane, the following areas
+   must be considered:
+
+      - MPLS PDU inspection
+      - MPLS PDU spoofing
+      - MPLS PDU alteration
+      - MPLS PSN protocol security
+      - Access Circuit security
+      - Denial-of-service prevention on the PE routers
+
+   When an MPLS PSN is used to provide pseudowire service, there is a
+   perception that security must be at least equal to the currently
+   deployed Layer 2 native protocol networks that the MPLS/PW network
+   combination is emulating.  This means that the MPLS-enabled network
+   SHOULD be isolated from outside packet insertion in such a way that
+   it SHOULD NOT be possible to insert an MPLS packet into the network
+   directly.  To prevent unwanted packet insertion, it is also important
+   to prevent unauthorized physical access to the PSN, as well as
+   unauthorized administrative access to individual network elements.
+
+   As mentioned above, an MPLS-enabled network should not accept MPLS
+   packets from its external interfaces (i.e., interfaces to CE devices
+   or to other providers' networks) unless the top label of the packet
+   was legitimately distributed to the system from which the packet is
+   being received.  If the packet's incoming interface leads to a
+   different Service Provider (SP) (rather than to a customer), an
+   appropriate trust relationship must also be present, including the
+   trust that the other SP also provides appropriate security measures.
+
+   The three main security problems faced when using an MPLS-enabled
+   network to transport PWs are spoofing, alteration, and inspection.
+   First, there is a possibility that the PE receiving PW PDUs will get
+   a PDU that appears to be from the PE transmitting the PW into the PSN
+   but that was not actually transmitted by the PE originating the PW.
+   (That is, the specified encapsulations do not by themselves enable
+   the decapsulator to authenticate the encapsulator.)  A second problem
+   is the possibility that the PW PDU will be altered between the time
+   it enters the PSN and the time it leaves the PSN (i.e., the specified
+   encapsulations do not by themselves assure the decapsulator of the
+   packet's integrity.)  A third problem is the possibility that the
+   PDU's contents will be seen while the PDU is in transit through the
+   PSN (i.e., the specification encapsulations do not ensure privacy.)
+   How significant these issues are in practice depends on the security
+   requirements of the applications whose traffic is being sent through
+   the tunnel and how secure the PSN itself is.
+
+
+
+
+Martini & Heron              Standards Track                   [Page 27]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+9.2.  Control-Plane Security
+
+   General security considerations with regard to the use of LDP are
+   specified in Section 5 of [RFC5036].  Those considerations also apply
+   to the case where LDP is used to set up pseudowires.
+
+   A pseudowire connects two Attachment Circuits.  It is important to
+   make sure that LDP connections are not arbitrarily accepted from
+   anywhere, or else a local Attachment Circuit might get connected to
+   an arbitrary remote Attachment Circuit.  Therefore, an incoming LDP
+   session request MUST NOT be accepted unless its IP source address is
+   known to be the source of an "eligible" LDP peer.  The set of
+   eligible peers could be preconfigured (either as a list of IP
+   addresses or as a list of address/mask combinations), or it could be
+   discovered dynamically via an auto-discovery protocol that is itself
+   trusted.  (Obviously, if the auto-discovery protocol were not
+   trusted, the set of eligible peers it produces could not be trusted.)
+
+   Even if an LDP connection request appears to come from an eligible
+   peer, its source address may have been spoofed.  Therefore, some
+   means of preventing source address spoofing must be in place.  For
+   example, if all the eligible peers are in the same network, source
+   address filtering at the border routers of that network could
+   eliminate the possibility of source address spoofing.
+
+   The LDP MD5 authentication key option, as described in Section 2.9 of
+   [RFC5036], MUST be implemented, and for a greater degree of security,
+   it must be used.  This provides integrity and authentication for the
+   LDP messages and eliminates the possibility of source address
+   spoofing.  Use of the MD5 option does not provide privacy, but
+   privacy of the LDP control messages is not usually considered
+   important.  As the MD5 option relies on the configuration of pre-
+   shared keys, it does not provide much protection against replay
+   attacks.  In addition, its reliance on pre-shared keys may make it
+   very difficult to deploy when the set of eligible neighbors is
+   determined by an auto-configuration protocol.
+
+   When the Generalized PWid FEC Element is used, it is possible that a
+   particular LDP peer may be one of the eligible LDP peers but may not
+   be the right one to connect to the particular Attachment Circuit
+   identified by the particular instance of the Generalized PWid FEC
+   Element.  However, given that the peer is known to be one of the
+   eligible peers (as discussed above), this would be the result of a
+   configuration error rather than a security problem.  Nevertheless, it
+   may be advisable for a PE to associate each of its local Attachment
+   Circuits with a set of eligible peers rather than have just a single
+   set of eligible peers associated with the PE as a whole.
+
+
+
+
+Martini & Heron              Standards Track                   [Page 28]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+10.  Interoperability and Deployment
+
+   Section 2.2 of [RFC6410] specifies four requirements that an Internet
+   Standard must meet.  This section documents how this document meets
+   those requirements.
+
+   The pseudowire technology was first deployed in 2001 and has been
+   widely deployed by many carriers.  [RFC7079] documents the results of
+   a survey of PW implementations with specific emphasis on control-word
+   usage.  [EANTC] documents a public multi-vendor interoperability test
+   of MPLS and Carrier Ethernet equipment, which included testing of
+   Ethernet, ATM, and TDM pseudowires.
+
+   The errata against [RFC4447] are generally editorial in nature and
+   have been addressed in this document.
+
+   All features in this specification have been implemented by multiple
+   vendors.
+
+   No IPR disclosures have been made to the IETF related to this
+   document, to RFCs 4447 or 6723, or to the Internet-Drafts that
+   resulted in RFCs 4447 and 6723.
+
+11.  References
+
+11.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>.
+
+   [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>.
+
+   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
+              <http://www.rfc-editor.org/info/rfc3032>.
+
+   [RFC4446]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+              Emulation (PWE3)", BCP 116, RFC 4446, DOI
+              10.17487/RFC4446, April 2006,
+              <http://www.rfc-editor.org/info/rfc4446>.
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 29]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   [RFC7358]  Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label
+              Advertisement Discipline for LDP Forwarding Equivalence
+              Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October
+              2014, <http://www.rfc-editor.org/info/rfc7358>.
+
+11.2.  Informative References
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
+              January 1998, <http://www.rfc-editor.org/info/rfc2277>.
+
+   [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>.
+
+   [RFC4842]  Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
+              "Synchronous Optical Network/Synchronous Digital Hierarchy
+              (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC
+              4842, DOI 10.17487/RFC4842, April 2007,
+              <http://www.rfc-editor.org/info/rfc4842>.
+
+   [RFC4553]  Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
+              Agnostic Time Division Multiplexing (TDM) over Packet
+              (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
+              <http://www.rfc-editor.org/info/rfc4553>.
+
+   [RFC4619]  Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
+              "Encapsulation Methods for Transport of Frame Relay over
+              Multiprotocol Label Switching (MPLS) Networks", RFC 4619,
+              DOI 10.17487/RFC4619, September 2006,
+              <http://www.rfc-editor.org/info/rfc4619>.
+
+   [RFC4717]  Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N.,
+              Brayley, J., and G. Koleyni, "Encapsulation Methods for
+              Transport of Asynchronous Transfer Mode (ATM) over MPLS
+              Networks", RFC 4717, DOI 10.17487/RFC4717, December 2006,
+              <http://www.rfc-editor.org/info/rfc4717>.
+
+   [RFC4618]  Martini, L., Rosen, E., Heron, G., and A. Malis,
+              "Encapsulation Methods for Transport of PPP/High-Level
+              Data Link Control (HDLC) over MPLS Networks", RFC 4618,
+              DOI 10.17487/RFC4618, September 2006,
+              <http://www.rfc-editor.org/info/rfc4618>.
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 30]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   [RFC4448]  Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
+              "Encapsulation Methods for Transport of Ethernet over MPLS
+              Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
+              <http://www.rfc-editor.org/info/rfc4448>.
+
+   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
+              G. Heron, "Pseudowire Setup and Maintenance Using the
+              Label Distribution Protocol (LDP)", RFC 4447, DOI
+              10.17487/RFC4447, April 2006,
+              <http://www.rfc-editor.org/info/rfc4447>.
+
+   [RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
+              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
+              DOI 10.17487/RFC6410, October 2011,
+              <http://www.rfc-editor.org/info/rfc6410>.
+
+   [RFC6723]  Jin, L., Ed., Key, R., Ed., Delord, S., Nadeau, T., and S.
+              Boutros, "Update of the Pseudowire Control-Word
+              Negotiation Mechanism", RFC 6723, DOI 10.17487/RFC6723,
+              September 2012, <http://www.rfc-editor.org/info/rfc6723>.
+
+   [RFC7079]  Del Regno, N., Ed., and A. Malis, Ed., "The Pseudowire
+              (PW) and Virtual Circuit Connectivity Verification (VCCV)
+              Implementation Survey Results", RFC 7079, DOI
+              10.17487/RFC7079, November 2013,
+              <http://www.rfc-editor.org/info/rfc7079>.
+
+   [ANSI]     American National Standards Institute, "Telecommunications
+              - Synchronous Optical Network (SONET) - Basic Description
+              Including Multiplex Structures, Rates, and Formats", ANSI
+              T1.105, October 1995.
+
+   [ITUG]     International Telecommunications Union, "Network node
+              interface for the synchronous digital hierarchy (SDH)",
+              ITU-T Recommendation G.707, May 1996.
+
+   [EANTC]    European Advanced Networking Test Center, "MPLS and
+              Carrier Ethernet: Service - Connect - Transport. Public
+              Multi-Vendor Interoperability Test", February 2009.
+
+Acknowledgments
+
+   The authors wish to acknowledge the contributions of Vach Kompella,
+   Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds.  The authors wish
+   to also acknowledge the contribution of the authors of RFC 6723,
+   whose work has been incorporated in this document: Lizhong Jin,
+   Raymond Key, Simon Delord, Tom Nadeau, and Sami Boutros.
+
+
+
+
+Martini & Heron              Standards Track                   [Page 31]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+Contributors
+
+   The following individuals were either authors or contributing authors
+   for RFC 4447.  They are listed here in recognition of their work on
+   that document.
+
+   Nasser El-Aawar
+   Level 3 Communications, LLC.
+   1025 Eldorado Blvd.
+   Broomfield, CO 80021
+   United States of America
+
+   Email: nna@level3.net
+
+
+   Eric C.  Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+   United States of America
+
+   Email: erosen@cisco.com
+
+
+   Dan Tappan
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+   United States of America
+
+   Email: tappan@cisco.com
+
+
+   Toby Smith
+   Google
+   6425 Penn Ave. #700
+   Pittsburgh, PA 15206
+   United States of America
+
+   Email: tob@google.com
+
+
+   Dimitri Vlachos
+   Riverbed Technology
+
+   Email: dimitri@riverbed.com
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 32]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   Jayakumar Jayakumar
+   Cisco Systems Inc.
+   3800 Zanker Road, MS-SJ02/2
+   San Jose, CA 95134
+   United States of America
+
+   Email: jjayakum@cisco.com
+
+
+   Alex Hamilton,
+   Cisco Systems Inc.
+   485 East Tasman Drive, MS-SJC07/3
+   San Jose, CA 95134
+   United States of America
+
+   Email: tahamilt@cisco.com
+
+
+   Steve Vogelsang
+   ECI Telecom
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+   United States of America
+
+   Email: stephen.vogelsang@ecitele.com
+
+
+   John Shirron
+   ECI Telecom
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+   United States of America
+
+   Email: john.shirron@ecitele.com
+
+
+   Andrew G. Malis
+   Verizon
+   60 Sylvan Rd.
+   Waltham, MA 02451
+   United States of America
+
+   Email: andrew.g.malis@verizon.com
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 33]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+   Vinai Sirkay
+   Reliance Infocomm
+   Dhirubai Ambani Knowledge City
+   Navi Mumbai 400 709
+   India
+
+   Email: vinai@sirkay.com
+
+
+   Vasile Radoaca
+   Nortel Networks
+   600  Technology Park
+   Billerica MA 01821
+   United States of America
+
+   Email: vasile@nortelnetworks.com
+
+
+   Chris Liljenstolpe
+   149 Santa Monica Way
+   San Francisco, CA 94127
+   United States of America
+
+   Email: ietf@cdl.asgaard.org
+
+
+   Dave Cooper
+   Global Crossing
+   960 Hamlin Court
+   Sunnyvale, CA 94089
+   United States of America
+
+   Email: dcooper@gblx.net
+
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+   United States of America
+
+   Email: kireeti@juniper.net
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 34]
+
+RFC 8077                     PWE3 Using LDP                February 2017
+
+
+Authors' Addresses
+
+   Luca Martini (editor)
+   Cisco Systems, Inc.
+   1899 Wynkoop Street, Suite 600
+   Denver, CO 80202
+   United States of America
+
+   Email: lmartini@monoski.com
+
+
+   Giles Heron (editor)
+   Cisco Systems
+   10 New Square
+   Bedfont Lakes
+   Feltham
+   Middlesex
+   TW14 8HA
+   United Kingdom
+
+   Email: giheron@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini & Heron              Standards Track                   [Page 35]
+