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.
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.
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>>.
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.
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
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
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.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
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 |