doc: Add RFC documents

1 files changed, 1851 insertions, 0 deletions

diff --git a/doc/rfc/rfc4447.txt b/doc/rfc/rfc4447.txt
new file mode 100644
index 0000000..31ddb95
--- /dev/null
+++ b/doc/rfc/rfc4447.txt
@@ -0,0 +1,1851 @@
+
+
+
+
+
+
+Network Working Group                                    L. Martini, Ed.
+Request for Comments: 4447                                      E. Rosen
+Category: Standards Track                            Cisco Systems, Inc.
+                                                             N. El-Aawar
+                                            Level 3 Communications, LLC.
+                                                                T. Smith
+                                                 Network Appliance, Inc.
+                                                                G. Heron
+                                                                 Tellabs
+                                                              April 2006
+
+
+                    Pseudowire Setup and Maintenance
+              Using the Label Distribution Protocol (LDP)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+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 (PDU) and transmitting
+   them over "pseudowires".  It is also possible to use pseudowires to
+   provide low-rate Time Division Multiplexed and a Synchronous Optical
+   NETworking circuit emulation over an MPLS-enabled network.  This
+   document specifies a protocol for establishing and maintaining the
+   pseudowires, using extensions to Label Distribution Protocol (LDP).
+   Procedures for encapsulating Layer 2 PDUs are specified in a set of
+   companion documents.
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 1]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Specification of Requirements ...................................5
+   3. The Pseudowire Label ............................................5
+   4. Details Specific to Particular Emulated Services ................7
+      4.1. IP Layer 2 Transport .......................................7
+   5. LDP .............................................................7
+      5.1. LDP Extensions .............................................8
+      5.2. The PWid FEC Element .......................................8
+      5.3. The Generalized PWid FEC Element ..........................10
+           5.3.1. Attachment Identifiers .............................11
+           5.3.2. Encoding the Generalized ID FEC Element ............13
+                  5.3.2.1. Interface Parameters TLV ..................14
+                  5.3.2.2. PW Grouping TLV ...........................14
+           5.3.3. Signaling Procedures ...............................15
+      5.4. Signaling of Pseudowire Status ............................16
+           5.4.1. Use of Label Mappings Messages .....................16
+           5.4.2. Signaling PW Status ................................17
+           5.4.3. Pseudowire Status Negotiation Procedures ...........18
+      5.5. Interface Parameters Sub-TLV ..............................19
+   6. Control Word ...................................................20
+      6.1. PW Types for Which the Control Word is REQUIRED ...........20
+      6.2. PW Types for Which the Control Word is NOT Mandatory ......21
+      6.3. LDP Label Withdrawal Procedures ...........................22
+      6.4. Sequencing Considerations .................................23
+           6.4.1. Label Advertisements ...............................23
+           6.4.2. Label Release ......................................24
+   7. IANA Considerations ............................................24
+      7.1. LDP TLV TYPE ..............................................24
+      7.2. LDP Status Codes ..........................................24
+      7.3. FEC Type Name Space .......................................25
+   8. Security Considerations ........................................25
+      8.1. Data-Plane Security .......................................25
+      8.2. Control-Plane Security ....................................26
+   9. Acknowledgements ...............................................27
+   10. Normative References ..........................................27
+   11. Informative References ........................................27
+   12. Additional Contributing Authors ...............................28
+   Appendix A. C-bit Handling Procedures Diagram .....................31
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 2]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+1.  Introduction
+
+   In [FRAME], [ATM], [PPPHDLC], and [ETH], it is explained 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 demultiplexor field, will be prepended to
+   the encapsulated PDU.  The pseudowire demultiplexor field is
+   prepended before transmitting a packet on a pseudowire.  When the
+   packet arrives at the remote endpoint of the pseudowire, the
+   demultiplexor 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.
+
+   Accompanying documents [CEP, SAToP] specify 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)[SDH]/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 demultiplexor and a PSN tunnel header is
+   prepended to this encapsulation.
+
+   [SAToP] describes methods for transporting low-rate time-division
+   multiplexing (TDM) digital signals (TDM circuit emulation) over PSNs,
+   while [CEP] 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.  [SAToP] 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 [RFC3036], as a protocol for setting up and maintaining
+   the pseudowires.  In particular, we define new TLVs, 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 demultiplexor
+   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.
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 3]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   In the protocol specified herein, the pseudowire demultiplexor 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, et al.             Standards Track                     [Page 4]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   +-----------------+                           +-----------------+
+   |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 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.  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].
+
+3.  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.
+
+
+
+Martini, et al.             Standards Track                     [Page 5]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   (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 demultiplexor 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 AAL5 PDU,
+   the PW label will generally correspond to a particular ATM VC at PE2.
+   That is, PE2 needs to be able to infer from the PW label the outgoing
+   interface and the VPI/VCI 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 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 uni-directional and will be repeated independently for
+   bi-directional operation.  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 be used in its
+   "downstream unsolicited" mode.  LDP's "liberal label retention" mode
+   SHOULD be used.
+
+
+
+
+Martini, et al.             Standards Track                     [Page 6]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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.
+
+   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 identify 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.
+
+4.  Details Specific to Particular Emulated Services
+
+4.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.
+
+5.  LDP
+
+   The PW label bindings are distributed using the LDP downstream
+   unsolicited mode described in [RFC3036].  The PEs will establish an
+   LDP session using the Extended Discovery mechanism described in [LDP,
+   sections 2.4.2 and 2.5].
+
+   An LDP Label Mapping message contains an 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.
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 7]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   The LDP base specification has several kinds of label TLVs, including
+   the Generic Label TLV, as specified in [RFC3036], section 3.4.2.1.
+   For setting up and maintaining pseudowires, the Generic Label TLV
+   MUST be used.
+
+5.1.  LDP Extensions
+
+   This document specifies no new LDP messages.
+
+   This document specifies the following new TLVs to be used with LDP:
+
+   TLV                    Specified in Section     Defined for Message
+   ===================================================================
+   PW Status TLV                  5.4.2            Notification
+   PW Interface Parameters TLV    5.3.2.1          FEC
+   PW Grouping  ID TLV            5.3.2.2          FEC
+
+
+   Additionally, the following new FEC element types are defined:
+
+   FEC Element Type        Specified in Section    Defined for Message
+   ===================================================================
+   0x80                            5.2             FEC
+   0x81                            5.3             FEC
+
+   The following new LDP error codes are also defined:
+
+   Status Code                                     Specified in Section
+   ====================================================================
+   "Illegal C-Bit"                                         6.1
+   "Wrong C-Bit"                                           6.2
+   "Incompatible bit-rate"                                [CEP]
+   "CEP/TDM mis-configuration"                            [CEP]
+   "PW status"                                            5.4.2
+   "Unassigned/Unrecognized TAI"                          5.3.3
+   "Generic Misconfiguration Error"                      [SAToP]
+   "Label Withdraw PW Status Method Not Supported"        5.4.1
+
+5.2.  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.
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                     [Page 8]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   For this purpose, a new type of FEC element is defined.  The FEC
+   element type is 0x80 and is defined 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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |  PWid (0x80)  |C|         PW type             |PW info Length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                          Group ID                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                           PW ID                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                Interface Parameter  Sub-TLV                   |
+   |                              "                                |
+   |                              "                                |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   -  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)" [IANA].
+
+   -  Control word bit (C)
+
+      The bit (C) 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 the section "C-Bit Handling Procedures" for further
+      explanation.
+
+   -  PW information length
+
+      Length of the PW ID field and the interface parameters sub-TLV 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 ID at ingress could be
+      part of the virtual tunnel for transport to the egress router.
+
+
+
+Martini, et al.             Standards Track                     [Page 9]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+      The Group ID is very useful for sending wild card label
+      withdrawals, or PW wild card status notification messages to
+      remote PEs upon physical port failure.
+
+   -  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.
+
+5.3.  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 Grouping TLV", described below.  The Interface
+   Parameters field of the PWid FEC element is also absent; its
+   functionality is replaced by the optional Interface Parameters TLV,
+   described below.
+
+
+
+Martini, et al.             Standards Track                    [Page 10]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+5.3.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>>,
+
+   The PW direction from PE2 to PE1 can be identified by:
+
+      <PE2, <AGI, AII2>, PE1, <AGI, AII1>>.
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 11]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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 ID
+   FEC element must specify the rules for performing this association.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 12]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+5.3.2.  Encoding the Generalized ID 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 the [IANA]
+   document.
+
+   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 specified grouping ID.  In this case,
+   there are no other FEC element fields (AGI, SAII, etc.) present, nor
+   any 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, et al.             Standards Track                    [Page 13]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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.
+
+5.3.2.1.  Interface Parameters TLV
+
+   This TLV MUST only be used when sending the Generalized PW 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 the section
+   "Interface Parameters Sub-TLV", below.
+
+5.3.2.2.  PW Grouping 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 Grouping ID TLV (0x096C)|            Length             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                             Value                             |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The PW Grouping 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 Grouping ID can be used as a port index and assigned to all PWs
+   that lead to that port.  Use of the PW Grouping ID enables one to
+   send "wild card" label withdrawals, or "wild card" status
+   notification messages, to remote PEs upon physical port failure.
+
+   Note Well: The PW Grouping ID is different from, and has no relation
+   to, the Attachment Group Identifier.
+
+   The PW Grouping ID TLV is not part of the FEC and will not be
+   advertised except in the PW FEC advertisement.  The advertising PE
+
+
+
+Martini, et al.             Standards Track                    [Page 14]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   MAY use the wild card withdraw semantics, but the remote PEs MUST
+   implement support for wild card messages.  This TLV MUST only be used
+   when sending the Generalized PW ID FEC.
+
+   To issue a wildcard command (status or withdraw):
+
+   -  Set the PW Info Length to 0 in the Generalized ID FEC Element.
+
+   -  Send only the PW Grouping ID TLV with the FEC (no AGI/SAII/TAII is
+      sent).
+
+5.3.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
+   autodiscovery 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 Services (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 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 being released (but without the
+   interface parameter TLV).  More generally, the FEC TLV is the same in
+   all LDP messages relating to the same PW.  In a Label Release, this
+   means that the SAII is the remote peer's AII and the TAII is the
+   sender's local AII.
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 15]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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 [RFC3036].
+
+   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.
+
+5.4.  Signaling of Pseudowire Status
+
+5.4.1.  Use of Label Mappings 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, et al.             Standards Track                    [Page 16]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+5.4.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 the PW IANA
+   Allocations document [IANA].  The length 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.  The general format of the Notification Message
+   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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |0|   Notification (0x0001)     |      Message Length           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Message ID                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Status (TLV)                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      PW Status TLV                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           PWId FEC TLV or Generalized ID FEC TLV              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 17]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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 and Message Type
+   fields are 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.  When a PE's
+   attachment circuit encounters an error, use of the PW Notification
+   Message allows the PE to send a single "wild card" 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 Grouping ID TLV.
+
+   As mentioned above, the Group ID field of the PWid FEC element, or
+   the PW Grouping ID TLV used with the Generalized ID 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
+   Grouping ID TLV is included, and the Interface Parameters TLV is
+   omitted.  For the purpose of this document, this is called the "wild
+   card 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.
+
+5.4.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, et al.             Standards Track                    [Page 18]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+    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 ID 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.
+
+5.5.  Interface Parameters 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, et al.             Standards Track                    [Page 19]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+    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 interface parameter sub-TLV type values are specified in "IANA
+   Allocations for Pseudowire Edge to Edge Emulation (PWE3)" [IANA].
+
+   The Length field is defined as the length of the interface parameter
+   including the parameter id and length field itself.  Processing of
+   the interface parameters should continue when unknown interface
+   parameters are encountered, and they MUST be silently ignored.
+
+   -  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.  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.  Control Word
+
+6.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.
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 20]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+6.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.
+
+       -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).
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 21]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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, but do not respond.
+            Continue to wait for the next control message for the PW.
+
+   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 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 is has no extra protocol to execute; it just waits for a Label
+   Mapping message that has c=0.
+
+   The diagram in Appendix A illustrates the above procedure.
+
+6.3.  LDP Label Withdrawal Procedures
+
+   As mentioned above, the Group ID field of the PWid FEC element, or
+   the PW Grouping ID TLV used with the Generalized ID 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.
+
+
+
+Martini, et al.             Standards Track                    [Page 22]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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
+   Grouping ID TLV is included, the Interface Parameters TLV is not
+   present, and the Label TLV is not present.  For the purpose of this
+   document, this is called the "wild card withdraw procedure", and all
+   PEs implementing this design are REQUIRED to accept such withdrawn
+   message but are not required to send it.  Note that the PW Grouping
+   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 wild card Label
+   Release message MUST include only the group ID, or Grouping ID TLV.
+   A Label Release message initiated by a PE router must always include
+   the PW ID.
+
+6.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.
+
+6.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 (re-use) 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
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 23]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   attempting to re-advertise a recently released label.  This is only
+   an issue when sequence number processing is enabled at the
+   disposition router.
+
+6.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 the section on
+   Label Advertisements.
+
+7.  IANA Considerations
+
+7.1.  LDP TLV TYPE
+
+   This document uses several new LDP TLV types; IANA already maintains
+   a registry of name "TLV TYPE NAME SPACE" defined by RFC 3036.  The
+   following values are suggested for assignment:
+
+      TLV type  Description
+      =====================================
+       0x096A   PW Status TLV
+       0x096B   PW Interface Parameters TLV
+       0x096C   Group ID TLV
+
+7.2.  LDP Status Codes
+
+   This document uses several new LDP status codes; IANA already
+   maintains a registry of name "STATUS CODE NAME SPACE" defined by RFC
+   3036.  The following values are suggested for assignment:
+
+   Range/Value     E     Description                       Reference
+   ------------- -----   ----------------------            ---------
+   0x00000024      0     Illegal C-Bit                     [RFC4447]
+   0x00000025      0     Wrong C-Bit                       [RFC4447]
+   0x00000026      0     Incompatible bit-rate             [RFC4447]
+   0x00000027      0     CEP-TDM mis-configuration         [RFC4447]
+   0x00000028      0     PW Status                         [RFC4447]
+   0x00000029      0     Unassigned/Unrecognized TAI       [RFC4447]
+   0x0000002A      0     Generic Misconfiguration Error    [RFC4447]
+   0x0000002B      0     Label Withdraw PW Status Method   [RFC4447]
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 24]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+7.3.  FEC Type Name Space
+
+   This document uses two new FEC element types, 0x80 and 0x81, from the
+   registry "FEC Type Name Space" for the Label Distribution Protocol
+   (LDP RFC 3036).
+
+8.  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 treat the security considerations for both the data
+   plane and the control plane.
+
+8.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, as 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 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.
+
+
+
+Martini, et al.             Standards Track                    [Page 25]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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.
+
+8.2.  Control-Plane Security
+
+   General security considerations with regard to the use of LDP are
+   specified in section 5 of RFC 3036.  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 pre-configured (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
+   RFC 3036, 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-
+
+
+
+Martini, et al.             Standards Track                    [Page 26]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   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 ID 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 ID 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.
+
+9.  Acknowledgements
+
+   The authors wish to acknowledge the contributions of Vach Kompella,
+   Vanson Lim, Wei Luo, Himanshu Shah, and Nick Weeds.
+
+10.  Normative References
+
+   [RFC2119] Bradner S., "Key words for use in RFCs to Indicate
+             Requirement Levels", RFC 2119, March 1997
+
+   [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
+             B. Thomas, "LDP Specification", RFC 3036, January 2001.
+
+   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
+             Encoding", RFC 3032, January 2001.
+
+   [IANA]    Martini, L., "IANA Allocations for Pseudowire Edge to Edge
+             Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
+
+11.  Informative References
+
+   [CEP]     Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
+             "SONET/SDH Circuit Emulation Service Over Packet (CEP)",
+             Work in Progress.
+
+   [SAToP]   Vainshtein, A., Ed. and Y. Stein, Ed., "Structure-Agnostic
+             TDM over Packet (SAToP)", Work in Progress.
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 27]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   [FRAME]   Martini, L., Ed. and C. Kawa, Ed., "Encapsulation Methods
+             for Transport of Frame Relay Over MPLS Networks", Work in
+             Progress.
+
+   [ATM]     Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed.,
+             "Encapsulation Methods for Transport of ATM Over MPLS
+             Networks", Work in Progress.
+
+   [PPPHDLC] Martini, L., Rosen, E., Heron, G., and A. Malis,
+             "Encapsulation Methods for Transport of PPP/HDLC Frames
+             Over IP and MPLS Networks", Work in Progress.
+
+   [ETH]     Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
+             "Encapsulation Methods for Transport of Ethernet Over MPLS
+             Networks", RFC 4448, April 2006.
+
+   [SDH]     American National Standards Institute, "Synchronous Optical
+             Network Formats," ANSI T1.105-1995.
+
+   [ITUG]    ITU Recommendation G.707, "Network Node Interface For The
+             Synchronous Digital Hierarchy", 1996.
+
+   [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge
+             (PWE3) Architecture", RFC 3985, March 2005.
+
+   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
+             Languages", BCP 18, RFC 2277, January 1998.
+
+12.  Additional Contributing Authors
+
+   Dimitri Stratton Vlachos
+   Mazu Networks, Inc.
+   125 Cambridgepark Drive
+   Cambridge, MA 02140
+
+   EMail: d@mazunetworks.com
+
+
+   Jayakumar Jayakumar,
+   Cisco Systems Inc.
+   225, E.Tasman, MS-SJ3/3,
+   San Jose, CA, 95134
+
+   EMail: jjayakum@cisco.com
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 28]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   Alex Hamilton,
+   Cisco Systems Inc.
+   285 W. Tasman, MS-SJCI/3/4,
+   San Jose, CA, 95134
+
+   EMail: tahamilt@cisco.com
+
+
+   Steve Vogelsang
+   ECI Telecom
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+
+   EMail: stephen.vogelsang@ecitele.com
+
+
+   John Shirron
+   ECI Telecom
+   Omega Corporate Center
+   1300 Omega Drive
+   Pittsburgh, PA 15205
+
+   EMail: john.shirron@ecitele.com
+
+
+   Andrew G. Malis
+   Tellabs
+   90 Rio Robles Dr.
+   San Jose, CA 95134
+
+   EMail: Andy.Malis@tellabs.com
+
+
+   Vinai Sirkay
+   Redback Networks
+   300 Holger Way
+   San Jose, CA 95134
+
+   EMail: vsirkay@redback.com
+
+
+   Vasile Radoaca
+   Nortel Networks
+   600  Technology Park
+   Billerica MA 01821
+
+   EMail: vasile@nortelnetworks.com
+
+
+
+Martini, et al.             Standards Track                    [Page 29]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+   Chris Liljenstolpe
+   Alcatel
+   11600 Sallie Mae Dr.
+   9th Floor
+   Reston, VA 20193
+
+   EMail: chris.liljenstolpe@alcatel.com
+
+
+   Dave Cooper
+   Global Crossing
+   960 Hamlin Court
+   Sunnyvale, CA 94089
+
+   EMail: dcooper@gblx.net
+
+
+   Kireeti Kompella
+   Juniper Networks
+   1194 N. Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: kireeti@juniper.net
+
+
+   Dan Tappan
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: tappan@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 30]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+Appendix A.  C-bit Handling Procedures Diagram
+
+                   ------------------
+               Y   | Received Label |       N
+            -------|  Mapping Msg?  |--------------
+            |      ------------------             |
+        --------------                            |
+        |            |                            |
+     -------      -------                         |
+     | C=0 |      | C=1 |                         |
+     -------      -------                         |
+        |            |                            |
+        |    ----------------                     |
+        |    | Control Word |     N               |
+        |    |    Capable?  |-----------          |
+        |    ----------------          |          |
+        |          Y |                 |          |
+        |            |                 |          |
+        |   ----------------           |          |
+        |   | Control Word |  N        |          |
+        |   |  Preferred?  |----       |          |
+        |   ----------------   |       |          |
+        |          Y |         |       |          |
+        |            |         |       |   ----------------
+        |            |         |       |   | Control Word |
+        |            |         |       |   |  Preferred?  |
+        |            |         |       |   ----------------
+        |            |         |       |     N |     Y |
+        |            |         |       |       |       |
+      Send         Send      Send    Send    Send    Send
+       C=0          C=1       C=0     C=0     C=0     C=1
+                               |       |       |       |
+                            ----------------------------------
+                            | If receive the same as sent,   |
+                            | PW setup is complete. If not:  |
+                            ----------------------------------
+                               |       |       |       |
+                              ------------------- -----------
+                              |     Receive     | | Receive |
+                              |       C=1       | |   C=0   |
+                              ------------------- -----------
+                                       |               |
+                                 Wait for the        Send
+                                 next message     Wrong C-Bit
+                                                       |
+                                                  Send Label
+                                               Mapping Message
+
+
+
+
+Martini, et al.             Standards Track                    [Page 31]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+Authors' Addresses
+
+   Luca Martini
+   Cisco Systems, Inc.
+   9155 East Nichols Avenue, Suite 400
+   Englewood, CO, 80112
+
+   EMail: lmartini@cisco.com
+
+
+   Nasser El-Aawar
+   Level 3 Communications, LLC.
+   1025 Eldorado Blvd.
+   Broomfield, CO, 80021
+
+   EMail: nna@level3.net
+
+
+   Giles Heron
+   Tellabs
+   Abbey Place
+   24-28 Easton Street
+   High Wycombe
+   Bucks
+   HP11 1NT
+   UK
+
+   EMail: giles.heron@tellabs.com
+
+
+   Eric C. Rosen
+   Cisco Systems, Inc.
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   EMail: erosen@cisco.com
+
+
+   Toby Smith
+   Network Appliance, Inc.
+   800 Cranberry Woods Drive
+   Suite 300
+   Cranberry Township, PA 16066
+
+   EMail: tob@netapp.com
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 32]
+
+RFC 4447                     PWE3 Using LDP                   April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Martini, et al.             Standards Track                    [Page 33]
+