summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8077.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8077.txt')
-rw-r--r--doc/rfc/rfc8077.txt1963
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]
+