Ethernet VPN Signalling Extensions for Bit-stream VPWS

Status of This Memo

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 20 October 2024.¶

Copyright Notice

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.¶

Table of Contents

1. Introduction and Motivation

Virtual Private Wire Service (VPWS) is a widely deployed technology for providing point-to-point (P2P) services for various layer 2 and also layer 1 technologies. Initially VPWS were define in the Pseudowire Emulation Edge-to-Edge (PWE3) architecture [RFC3985] for Frame Relay, ATM, HDLC, PPP, Ethernet, TDM and SONET/SDH.¶

How Ethernet VPWS can be signalled using Ethernet VPN has already been specified in [RFC8214]. This document is defining necessary signalling extension for Ethernet VPN to also support the following bit stream VPWS instance types:¶

• TDM services using SAToP [RFC4553]¶

• TDM services using CESoP [RFC5086]¶

• SONET/SDH services using CEP [RFC4842]¶

• Private line services using PLE [I-D.ietf-pals-ple]¶

A generic VPWS reference model similar to the one defined in [RFC3985] and [I-D.ietf-pals-ple] is shown in Figure 1. Data received from a CEs is encapsulated by PEs into the respective VPWS established between the attachment circuits of the local and remote PE and transmitted across the Packet Switched Network (PSN) using a PSN tunnel.¶

CE1 & CE2 physical                       CE3 & CE4 physical
  interfaces                                interfaces
       |      <------- PSN tunnels ----->      |
       |    +-----------------------------+    |
       |    |                             |    |
+---+  v  +---+                         +---+  v  +---+
|CE1|-----|   |.......... VPWS1 ........|PE2|-----|CE3|
+---+     |   |                         +---+     +---+
          |PE1| packet switched network   |
+----     |   |                         +---+     +---+
|CE2|-----|   |.......... VPWS2 ........|PE3|-----|CE4|
+---+     +---+                         +---+     +---+
          ^ |                             | ^
          | +-----------------------------+ |
          |                                 |
      attachment                       attachment
       circuits                         circuits
          |                                 |
          |<------ emulated services ------>|

2. Requirements Notation

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.¶

3. Terminology

• AIS - Alarm Indication Signal¶

• AFI - Address Family Identifier¶

• ATM - Asynchronous Transfer Mode¶

• BGP - Border Gateway Protocol¶

• CBR - Constant Bit Rate¶

• CE - Customer Edge¶

• CEP - SONET/SDH Circuit Emulation over Packet¶

• CESoP - Structure-aware TDM Circuit Emulation Service over Packet Switched Network¶

• DF - Designated Forwarder¶

• EAD - Ethernet Auto Discovery¶

• FC - Fibre Channel¶

• EBM - Equipped Bit Mask¶

• EVI - EVPN Instance¶

• EVPN - Ethernet Virtual Private Network¶

• HDLC - High-level Data Link Control¶

• LDP - Label Distribution Protocol¶

• MPLS - Multi Protocol Label Switching¶

• MTU - Maximum Transmission Unit¶

• NDF - Non-Designated Forwarder¶

• NLRI - Network Layer Reachability Information¶

• OC - Optical Carrier¶

• ODUk - Optical Data Unit k¶

• PDH - Plesynchronous Digital Hierarchy¶

• PE - Provider Edge¶

• PLE - Private Line Emulation¶

• PPP - Point-to-Point Protocol¶

• PSN - Packet Switched Network¶

• PW - Pseudo Wire¶

• PWE3 - Pseudowire Emulation Edge-to-Edge¶

• P2P - Point-to-Point¶

• RTP - Realtime Transport Protocol¶

• SAFI - Subsequent Address Family Identifier¶

• SAToP - Structure Agnostic TDM over Packet¶

• SDH - Synchronous Digital Hierarchy¶

• SONET - Synchronous Optical Network¶

• SRv6 - Segment Routing over IPv6 Dataplane¶

• STM - Synchronous Transport Module¶

• STS - Synchronous Transport Signal¶

• TDM - Time Division Multiplexing¶

• TLV - Type Length Value¶

• UNE - Unequipped¶

• VC - Virtual Circuit¶

• VPWS - Virtual Private Wire Service¶

• VT - Virtual Tributary¶

4. Solution Requirements

To avoid redefining PW types for [RFC8214] the notion of "PW type" from [RFC8077] is maintained and only a new PW type for [I-D.ietf-pals-ple] has been assigned by IANA.¶

• TBD1 - Private Line Emulation (PLE) over Packet¶

The concept of "CEP type" from [RFC5287] to distinguish different connection types that use the same PW type is adopted. In this document it is referred to as "PLE/CEP type". Two new connection types are defined Section 7.3.¶

To unambiguously identify the rate of an attachment circuit, also the concept of "CEP/TDM bit-rate" from [RFC5287] is adopted and called "PLE/CEP/TDM bit-rate" herein.¶

The VPWS signalling requirements are as follows:¶

• Implementations MUST support MPLS as underlay PSN¶

• The VPWS instance MAY be signalled as SRv6 overlay service per [RFC9252] leveraging on [RFC8986] using the End.DX2 function. In such case, the implementation MUST support SRv6 as underlay PSN.¶

• The use of control word MUST be signalled, as defined in [RFC4553], [RFC5086], [RFC4842] and [I-D.ietf-pals-ple].¶

• The PW type MUST be signalled and the PE nodes MUST validate that the PW type is identical on both endpoint.¶

• For CEP [RFC4842] and PLE [I-D.ietf-pals-ple] the PLE/CEP type MUST be signalled and the PE nodes MUST validate that the PLE/CEP type is identical on both endpoints.¶

• The PLE/CEP/TDM bit-rate MUST be signalled if the attachment circuit can not be unambiguously identified from the PW type alone and the PE nodes MUST validate that the attachment circuit is identical on both endpoints.¶

• A non-default payload size MAY be signalled. Both PE nodes MUST validate that the payload size is identical on both endpoints.¶

• A locally configured connection identifier as defined in Section 7.6 SHOULD be sent to the remote PE node. A locally configured expected identifier MAY be used to identify a misconnection by comparing it with the identifier received from the remote PE node.¶

• The multi-homed PE scenarios per [RFC7432] and [RFC8214] SHOULD be supported where the load-balancing mode single-active MUST be supported. Port-active load-balancing mode MAY also be supported.¶

• Multi-homed PE scenarios non-revertive mode MUST and revertive mode SHOULD be supported in compliance to [I-D.ietf-bess-evpn-pref-df].¶

5. Service Types

The following sections list all possible service types that are supported by the proposed signalling mechanisms.¶

6. Reuse of existing BGP EVPN-VPWS Capabilities

A PLE VPWS instance is identified by a pair of per-EVI ethernet A-D routes advertised by two PE nodes establishing the VPWS in accordance to [RFC8214].¶

The EVPN layer 2 attribute extended community defined in [RFC8214] MUST be supported and added to the per-EVI ethernet A-D route.¶

• C bit set to 1 to indicate Control Word MUST be present.¶

• P and B bits are set by dual-homing PEs as per [RFC8214] and [I-D.ietf-bess-evpn-pref-df]¶

• L2 MTU MUST be set to zero and ignored by the receiver¶

7. BGP Bitstream Attribute

To exchange and validate bit-stream specific attachment circuit parameters during the VPWS setup, a new BGP path attribute called "BGP Bitstream attribute" is defined.¶

The BGP bitstream attribute is an optional and transitive BGP path attribute with the attribute type codepoint TBD2.¶

The BGP Bitstream attribute can only be attached to Ethernet Auto-Discovery (A-D) routes (Route type 1) defined in [RFC7432]. The usage for other route types and Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not allow unless specified in future specifications.¶

The format is defined as a set of Type/Length/Value (TLV) triplets, described in the following sections and listed in Table 6. This attribute SHOULD only be included with EVPN Network Layer Reachability Information (NLRI).¶

• 1* PLE/CEP only¶

• 2* TDM only¶

For a particular PSN it is expected that the network operator will choose a common set of parameters per VPWS type, hence efficient BGP update packing as discussed in Section 12 of [RFC4277] is expected to happen.¶

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|           PW Type           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     PLE/CEP/TDM Bit-rate                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        PLE/CEP Options        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                                       1
 0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|AIS|UNE|RTP|EBM|      Reserved [0:6]       |  PLE/CEP  | Async |
|   |   |   |   |                           |    Type   |T3 |E3 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                         TDM Options                           |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   PLE/CEP/TDM Payload Bytes   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |             Length            |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
//                Endpoint Identifier (variable)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Control Plane Operations

The deployment model shown in figure 3 of [RFC8214] does equally apply to the operations defined in this document.¶

                    PSN
                 +---------+
    DF  +---+    |         |   +---+   +---+
     +--|PE1|----|---------|---|PE3|---|CE2|
+---+/   +---+    |   VPWS1/|   +---+   +---+
|CE1|             |       / |
+---+\   +---+    |      /  |
     +--|PE2|----|-----+   |
   NDF  +---+    |         |
                 +---------+

9. Mandatory Control Word

Both Section 18 of [RFC7432] and Section 3.1 of [RFC8214] do provide guidance on when the use of control should be signalled.¶

As the bit-stream VPWS types signalled via the mechanisms described in this document mandate a control word to be present, the use of control word MUST always be signalled independent of the underlying PSN characteristics.¶

10. Security Considerations

The same Security Considerations described in [RFC8214] are valid for this document.¶

11. IANA Considerations

This document defines a new BGP path attribute known as the "BGP bitstream attribute". IANA is requested to assign the codepoint TBD2 in the "BGP Path Attributes" registry to the BGP bitstream attribute.¶

This document defines a new PW Type for PLE VPWS. IANA is requested to assign the PW type value TBD1 to PLE in the "MPLS Pseudowire Types" registry.¶

12. Acknowledgements

to be added¶

Authors' Addresses