Internet-Draft | LDP Extensions for PLE | October 2024 |
Schmutzer | Expires 23 April 2025 | [Page] |
This document defines extension to the Pseudowire Emulation Edge-to-Edge (PWE3) control protocol [RFC4447] required for the setup of Private Line Emulation (PLE) pseudowires in MPLS networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC5287] has already specified extensions to the Label Distribution Protocol (LDP) for the setup of structure-agnostic TDM pseudowires specified in [RFC4533], structure-aware pseudowires specified in [RFC5086] and SONET/SDH Circuit Emulation over Packet (CEP) pseudowires in [RFC4842].¶
Private Line Emulation pseudowires are specified in [I-D.ietf-pals-ple]. This document focuses on the LDP definitions and extensions required for the setup of PLE pseudowires taking [RFC5287] and Section 12 of [RFC4842] as a starting point.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
to be added¶
The following sections list all possible service types that are supported by PLE and the proposed signalling mechanisms.¶
Service Type | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate |
---|---|---|---|
1000Base-X | TBD1 | 0x3 | 1,250,000 |
10GBASE-R | TBD1 | 0x3 | 10,312,500 |
25GBASE-R | TBD1 | 0x3 | 25,791,300 |
40GBASE-R | TBD1 | 0x3 | 41,250,000 |
50GBASE-R | TBD1 | 0x3 | 51,562,500 |
100GBASE-R | TBD1 | 0x3 | 103,125,000 |
200GBASE-R | TBD1 | 0x3 | 212,500,000 |
400GBASE-R | TBD1 | 0x3 | 425,000,000 |
Service Type | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate |
---|---|---|---|
1GFC | TBD1 | 0x3 | 1,062,500 |
2GFC | TBD1 | 0x3 | 2,125,000 |
4GFC | TBD1 | 0x3 | 4,250,000 |
8GFC | TBD1 | 0x3 | 8,500,000 |
10GFC | TBD1 | 0x3 | 10,518,750 |
16GFC | TBD1 | 0x3 | 14,025,000 |
32GFC | TBD1 | 0x3 | 28,050,000 |
64GFC | TBD1 | 0x3 | 57,800,000 |
128GFC | TBD1 | 0x3 | 112,200,000 |
Service Type | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate |
---|---|---|---|
ODU0 | TBD1 | 0x4 | 1,244,160 |
ODU1 | TBD1 | 0x4 | 2,498,775 |
ODU2 | TBD1 | 0x4 | 10,037,273 |
ODU2e | TBD1 | 0x4 | 10,399,525 |
ODU3 | TBD1 | 0x4 | 40,319,218 |
ODU4 | TBD1 | 0x4 | 104,794,445 |
Service Type | PW Type | PLE/CEP Type | PLE/CEP/TDM Bit-rate |
---|---|---|---|
OC3/STM1 | TBD1 | 0x3 | 155,520 |
OC12/STM4 | TBD1 | 0x3 | 622,080 |
OC48/STM16 | TBD1 | 0x3 | 2,488,320 |
OC192/STM64 | TBD1 | 0x3 | 9,953,280 |
OC768/STM256 | TBD1 | 0x3 | 39,813,120 |
[RFC4447] does define two types of PW Forwarding Equivalent Classes (FECs)¶
The Group ID and the Interface Parameters are contained in separate TLVs, called the PW Grouping TLV and the Interface Parameters TLV.¶
Either of these types of PW FEC MAY be used for the setup of PLE PWs with the PW type TBD1 and appropriate interface parameters.¶
Using the generalized PW FEC allows for uniquely identifying both PW endpoints and misconnection detection.¶
The two endpoints MUST agree on the PW type, as both directions of the PW are required to be of the same type.¶
The Control bit MUST be set as PLE PW encapsulation uses a control word.¶
The interface parameters that are relevant for the setup of PLE pseudowires are listed in Table 5¶
Interface Parameter | Sub-TLV | Length | Description |
---|---|---|---|
PLE/CEP/TDM Payload Bytes | 0x04 | 4 | Section 6.2 |
PLE/CEP/TDM Bit-Rate | 0x07 | 6 | Section 6.3 |
PLE/CEP Options | 0x05 | 4 | Section 6.4 |
The payload byte sub-TLV already defined in [RFC5287] does also apply to PLE and MAY be included if a non-default payload size is to be used. If this TLV is omitted then the default payload size defined in [I-D.ietf-pals-ple] MUST be assumed. The format of the PLE/CEP/TDM Payload Bytes sub-TLV is shown in Figure 1.¶
Type : 4¶
Length : 4¶
The total length in octets of the value portion of the TLV.¶
PLE/CEP/TDM Payload Bytes :¶
A two byte field denoting the desired payload size to be used.¶
The bit-rate sub-TLV already defined in [RFC5287] is MANDATORY for PLE pseudowires in order to unambiguously indicate the attachment circuit type. The format of the PLE/CEP/TDM Bit-Rate sub-TLV is shown in Figure 2.¶
Type : 7¶
Length : 6¶
The total length in octets of the value portion of the TLV.¶
PLE/CEP/TDM Bit-rate :¶
A four byte field denoting the data rate in units of 1-kbps¶
The options sub-TLV already defined in Section 12.3 of [RFC4842] MUST be present when signaling PLE pseudowires. The format of the PLE/CEP options sub-TLV is shown in Figure 3.¶
Type : 5¶
Length : 4¶
The total length in octets of the value portion of the TLV.¶
PLE/CEP Options :¶
AIS, UNE, RTP, EBM :¶
These bits MUST be set to zero and ignored by the receiver.¶
Reserved :¶
7-bit field for future use. MUST be set to ZERO and ignored by receiver.¶
CEP/PLE Type :¶
Indicates the connection type for CEP and PLE. CEP connection types are defined in [RFC4842]. Two new values for PLE are defined in this document:¶
0x3 - Basic PLE payload¶
0x4 - Byte aligned PLE payload¶
Async :¶
These bits MUST be set to zero and ignored by the receiver.¶
Per [RFC4447] in case of incompatible bit-rate the LDP status code 0x00000026 (incompatible bit-rate) and in case of incompatible PLE options the LDP status code 0x00000027 (CEP-TDM mis-configuration) has to be used to indicate the reason of failure to establish the pseudowire.¶
Setting of the Control bit to zero MUST result in an LDP status of 0x00000024 (Illegal C-Bit).¶
The PLE PW control word carries status indications for both attachment circuits (L bit) and the PSN (R bit) indication (see [I-D.ietf-pals-ple]). Similar functionality is available via use of the PW Status TLV (see Section 5.4.2 of [RFC4447]). If the latter mechanism is employed, the signaling PE sends its peer a PW Status TLV for this PW, setting the appropriate bits (see Section 3.5 of [RFC4446]):¶
Pseudowire Not Forwarding¶
Local Attachment Circuit (ingress) Receive Fault¶
Local Attachment Circuit (egress) Transmit Fault¶
Local PSN-facing PW (ingress) Receive Fault¶
Local PSN-facing PW (egress) Transmit Fault¶
As long as the TDM PW interworking function is operational, usage of the Status TLV is NOT RECOMMENDED in order to avoid contention between status indications reported by the data and control plane. However, if the TDM PW interworking function (IWF) itself fails while the PWE3 control plane remains operational, a Status TLV with all of the above bits set SHOULD be sent.¶
This document does not have any additional impact on the security of PWs above that of basic LDP-based setup of PWs specified in [RFC4447].¶
As already indicated in section 10 of [I-D.schmutzer-bess-bitstream-vpws-signalling], IANA is requested to assign a PW type (value TBD1) for PLE pseudowires from the "MPLS Pseudowire Types" registry.¶
to be added¶