Private Line Emulation over Packet Switched Networks
draft-ietf-pals-ple-10
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Steven Gringeri , Jeremy Whittaker , Nicolai Leymann , Christian Schmutzer , Chris Brown | ||
| Last updated | 2024-11-19 (Latest revision 2024-11-04) | ||
| Replaces | draft-schmutzer-pals-ple | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
TSVART Last Call review
(of
-09)
by Tommy Pauly
Ready w/nits
GENART Last Call review
(of
-08)
by Joel Halpern
Ready w/nits
INTDIR Telechat Review due 2024-11-30
Requested
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Stewart Bryant | ||
| Shepherd write-up | Show Last changed 2024-11-06 | ||
| IESG | IESG state | IESG Evaluation | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Gunter Van de Velde | ||
| Send notices to | stewart.bryant@gmail.com, agmalis@gmail.com | ||
| IANA | IANA review state | Version Changed - Review Needed |
draft-ietf-pals-ple-10
Network Working Group S. Gringeri
Internet-Draft J. Whittaker
Intended status: Standards Track Verizon
Expires: 9 May 2025 N. Leymann
Deutsche Telekom
C. Schmutzer, Ed.
Cisco Systems, Inc.
C. Brown
Ciena Corporation
5 November 2024
Private Line Emulation over Packet Switched Networks
draft-ietf-pals-ple-10
Abstract
This document describes methods and requirements for implementing the
encapsulation of high-speed bit-streams into virtual private wire
services (VPWS) over packet switched networks (PSN) providing
complete signal transport transparency.
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 9 May 2025.
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
Gringeri, et al. Expires 9 May 2025 [Page 1]
Internet-Draft PLE November 2024
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 . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Reference Model . . . . . . . . . . . . . . . 4
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Reference Models . . . . . . . . . . . . . . . . . . . . 7
4. Emulated Services . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Generic PLE Service . . . . . . . . . . . . . . . . . . . 9
4.2. Ethernet services . . . . . . . . . . . . . . . . . . . . 9
4.2.1. 1000BASE-X . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. 10GBASE-R and 25GBASE-R . . . . . . . . . . . . . . . 10
4.2.3. 40GBASE-R, 50GBASE-R and 100GBASE-R . . . . . . . . . 11
4.2.4. 200GBASE-R and 400GBASE-R . . . . . . . . . . . . . . 12
4.2.5. Energy Efficient Ethernet (EEE) . . . . . . . . . . . 14
4.3. SONET/SDH Services . . . . . . . . . . . . . . . . . . . 14
4.4. Fibre Channel Services . . . . . . . . . . . . . . . . . 15
4.4.1. 1GFC, 2GFC, 4GFC and 8GFC . . . . . . . . . . . . . . 15
4.4.2. 16GFC and 32GFC . . . . . . . . . . . . . . . . . . . 16
4.4.3. 64GFC and 4-lane 128GFC . . . . . . . . . . . . . . . 16
4.5. OTN Services . . . . . . . . . . . . . . . . . . . . . . 18
5. PLE Encapsulation Layer . . . . . . . . . . . . . . . . . . . 19
5.1. PSN and VPWS Demultiplexing Headers . . . . . . . . . . . 19
5.2. PLE Header . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. PLE Control Word . . . . . . . . . . . . . . . . . . 21
5.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 22
6. PLE Payload Layer . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Basic Payload . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Byte aligned Payload . . . . . . . . . . . . . . . . . . 24
7. PLE Operation . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Common Considerations . . . . . . . . . . . . . . . . . . 24
7.2. PLE IWF Operation . . . . . . . . . . . . . . . . . . . . 25
7.2.1. PSN-bound Encapsulation Behavior . . . . . . . . . . 25
7.2.2. CE-bound Decapsulation Behavior . . . . . . . . . . . 25
7.3. PLE Performance Monitoring . . . . . . . . . . . . . . . 27
7.4. PLE Fault Management . . . . . . . . . . . . . . . . . . 28
8. QoS and Congestion Control . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10.1. Bit-stream Next Header Type . . . . . . . . . . . . . . 30
10.2. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 30
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
Gringeri, et al. Expires 9 May 2025 [Page 2]
Internet-Draft PLE November 2024
12.1. Normative References . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction and Motivation
This document describes a method called Private Line Emulation (PLE)
for encapsulating high-speed bit-streams as Virtual Private Wire
Service (VPWS) over Packet Switched Networks (PSN).
This emulation suits applications, where carrying Protocol Data Units
(PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical
layer signal transparency is required and data or framing structure
interpretation of the PE would be counterproductive.
One example of such case is two Ethernet connected Customer Edge (CE)
devices and the need for Synchronous Ethernet operation between them
without the intermediate Provider Edge (PE) devices interfering or
addressing concerns about Ethernet control protocol transparency for
PDU based carrier Ethernet services, beyond the behavior definitions
of Metro Ethernet Forum (MEF) specifications.
Another example would be a Storage Area Networking (SAN) extension
between two data centers. Operating at a bit-stream level allows for
a connection between Fibre Channel switches without interfering with
any of the Fibre Channel protocol mechanisms.
Also, SONET/SDH add/drop multiplexers or cross-connects can be
interconnected without interfering with the multiplexing structures
and networks mechanisms. This is a key distinction to Circuit
Emulation over Packet (CEP) defined in [RFC4842] where demultiplexing
and multiplexing is desired in order to operate per SONET Synchronous
Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual
Container (VC). Said in another way, PLE does provide an independent
layer network underneath the SONET/SDH layer network, whereas CEP
does operate at the same level and peer with the SONET/SDH layer
network.
The mechanisms described in this document follow principles similar
to Structure-Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP) defined in [RFC4553]. The applicability is expanded beyond
the narrow set of PDH interfaces (T1, E1, T3 and E3) to allow the
transport of signals from many different technologies such as
Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at
gigabit speeds. The signals are treated as bit-stream payload which
was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3)
architecture in [RFC3985] sections 3.3.3 and 3.3.4.
Gringeri, et al. Expires 9 May 2025 [Page 3]
Internet-Draft PLE November 2024
2. Requirements Notation
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 RFC 2119.
3. Terminology and Reference Model
3.1. Terminology
* ACH - Associated Channel Header [RFC7212]
* AIS - Alarm Indication Signal
* AIS-L - Line AIS
* AS - Autonomous System
* ASBR - Autonomous System Border Router
* MS-AIS - Multiplex Section AIS
* BITS - Building Integrated Timing Supply
* CBR - Constant Bit Rate
* CE - Customer Edge
* CEP - Circuit Emulation over Packet [RFC4842]
* CSRC - Contributing SouRCe [RFC3550]
* DEG - Degradation
* ES - Errored Second
* FEC - Forward Error Correction
* ICMP - Internet Control Message Protocol [RFC792]
* IEEE - Institute of Electrical and Electronics Engineers
* INCITS - InterNational Committee for Information Technology
Standards
* IWF - InterWorking Function
* LDP - Label Distribution Protocol [RFC5036], [RFC8077]
Gringeri, et al. Expires 9 May 2025 [Page 4]
Internet-Draft PLE November 2024
* LF - Local Fault
* LOF - Loss Of Frame
* LOM - Loss Of Multiframe
* LOS - Loss Of Signal
* LPI - Low Power Idle
* LSP - Label Switched Path
* MEF - Metro Ethernet Forum
* MPLS - Multi Protocol Label Switching [RFC3031]
* NOS - Not Operational
* NSP - Native Service Processor [RFC3985]
* ODUk - Optical Data Unit k
* OTN - Optical Transport Network
* OTUk - Optical Transport Unit k
* PCS - Physical Coding Sublayer
* PDH - Plesiochronous Digital Hierarchy
* PDV - Packet Delay Variation
* PE - Provider Edge
* PLE - Private Line Emulation
* PLOS - Packet Loss Of Signal
* PLR - Packet Loss Ratio
* PMA - Physical Medium Attachment
* PMD - Physical Medium Dependent
* PSN - Packet Switched Network
* PTP - Precision Time Protocol
Gringeri, et al. Expires 9 May 2025 [Page 5]
Internet-Draft PLE November 2024
* PW - Pseudowire [RFC3985]
* PWE3 - Pseudo Wire Emulation Edge-to-Edge [RFC3985]
* P2P - Point-to-Point
* QOS - Quality Of Service
* RDI - Remote Defect Indication
* RSVP-TE - Resource Reservation Protocol Traffic Engineering
[RFC4875]
* RTCP - RTP Control Protocol [RFC3550]
* RTP - Realtime Transport Protocol [RFC3550]
* SAN - Storage Area Network
* SAToP - Structure-Agnostic Time Division Multiplexing (TDM) over
Packet [RFC4553]
* SD - Signal Degrade
* SES - Severely Errored Second
* SDH - Synchronous Digital Hierarchy
* SID - Segment Identifier [RFC8402]
* SPE - Synchronous Payload Envelope
* SR - Segment Routing [RFC8402]
* SRH - Segment Routing Header [RFC8402]
* SR-TE - Segment Routing Traffic Engineering [RFC9256]
* SRTP - Secure Realtime Transport Protocol [RFC3711]
* SRv6 - Segment Routing over IPv6 Dataplane [RFC8986]
* SSRC - Synchronization SouRCe [RFC3550]
* SONET - Synchronous Optical Network
* TCP - Transmission Control Protocol [RFC9293]
Gringeri, et al. Expires 9 May 2025 [Page 6]
Internet-Draft PLE November 2024
* TDM - Time Division Multiplexing
* TTS - Transmitter Training Signal
* UAS - Unavailable Second
* VPWS - Virtual Private Wire Service [RFC3985]
* VC - Virtual Circuit
* VT - Virtual Tributary
The term Interworking Function (IWF) is used to describe the
functional block that encapsulates bit streams into PLE packets and
in the reverse direction decapsulates PLE packets and reconstructs
bit streams.
3.2. Reference Models
The reference model for PLE is illustrated in Figure 1 and is inline
with the reference model defined in Section 4.1 of [RFC3985]. PLE
does rely on PWE3 pre-processing, in particular the concept of a
Native Service Processing (NSP) function defined in Section 4.2.2 of
[RFC3985].
|<--- p2p L2VPN service -->|
| |
| |<-PSN tunnel->| |
v v v v
+---------+ +---------+
| PE1 |==============| PE2 |
+---+-----+ +-----+---+
+-----+ | N | | | | N | +-----+
| CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 |
+-----+ ^ | P | | | | P | ^ +-----+
| +---+-----+ +-----+---+ |
CE1 physical ^ ^ CE2 physical
interface | | interface
|<--- emulated service --->|
| |
attachment attachment
circuit circuit
Figure 1: PLE Reference Model
PLE embraces the minimum intervention principle outlined in
Section 3.3.5 of [RFC3985] whereas the data is flowing through the
PLE encapsulation layer as received without modifications.
Gringeri, et al. Expires 9 May 2025 [Page 7]
Internet-Draft PLE November 2024
For some service types the NSP function is responsible for performing
operations on the native data received from the CE. Examples are
terminating Forward Error Correction (FEC), terminating the OTUk
layer for OTN or dealing with multi-lane processing. After the NSP,
the IWF is generating the payload of the VPWS which is carried via a
PSN tunnel.
To allow the clock of the transported signal to be carried across the
PLE domain in a transparent way the relative network synchronization
reference model and deployment scenario outlined in Section 4.3.2 of
[RFC4197] are applicable and are shown in Figure 2.
J
| G
| |
| +-----+ +-----+ v
+-----+ v |- - -|=================|- - -| +-----+
| |<---------|.............................|<---------| |
| CE1 | | PE1 | VPWS | PE2 | | CE2 |
| |--------->|.............................|--------->| |
+-----+ |- - -|=================|- - -| ^ +-----+
^ +-----+ +-----+ |
| ^ C D ^ |
A | | |
+-----------+-----------+ E
|
+-+
|I|
+-+
Figure 2: Relative Network Scenario Timing
The local oscillators C of PE1 and D of PE2 are locked to a common
clock I.
The attachment circuit clock E is generated by PE2 via a differential
clock recovery method in reference to the common clock I. For this
to work the difference between clock A and clock C (locked to I) MUST
be explicitly transferred from PE1 to PE2 using the timestamp inside
the RTP header.
For the reverse direction PE1 does generate the attachment circuit
clock J and the clock difference between G and D (locked to I)
transferred from PE2 to PE1.
Gringeri, et al. Expires 9 May 2025 [Page 8]
Internet-Draft PLE November 2024
The method used to lock clocks C and D to the common clock I is out
of scope of this document, but there are already several well
established concepts for achieving frequency synchronization
available.
While using external timing inputs (aka BITS) or synchronous Ethernet
as defined in [G.8261] the characteristics and limits defined in
[G.8262] have to be considered.
While relying on precision time protocol (PTP) as defined in
[G.8265.1], the network limits defined in [G.8261.1] have to be
considered.
4. Emulated Services
This specification describes the emulation of services from a wide
range of technologies, such as TDM, Ethernet, Fibre Channel, or OTN,
as bit streams or structured bit streams, as defined in Section 3.3.3
and Section 3.3.4 of [RFC3985].
4.1. Generic PLE Service
The generic PLE service is an example of the bit stream defined in
Section 3.3.3 of [RFC3985].
Under the assumption that the CE-bound IWF is not responsible for any
service specific operation, a bit stream of any rate can be carried
using the generic PLE payload.
There is no NSP function present for this service.
4.2. Ethernet services
Ethernet services are special cases of the structured bit stream
defined in Section 3.3.4 of [RFC3985].
IEEE has defined several layers for Ethernet in [IEEE802.3].
Emulation is operating at the physical (PHY) layer, more precisely at
the Physical Coding Sublayer (PCS).
Over time many different Ethernet interface types have been specified
in [IEEE802.3] with a varying set of characteristics such as optional
vs mandatory FEC and single-lane vs multi-lane transmission.
Ethernet interface types with backplane physical media dependent
(PMD) variants and ethernet interface types mandating auto-
negotiation (except 1000Base-X) are out of scope for this document.
Gringeri, et al. Expires 9 May 2025 [Page 9]
Internet-Draft PLE November 2024
All Ethernet services are leveraging the basic PLE payload and
interface specific mechanisms are confined to the respective service
specific NSP functions.
4.2.1. 1000BASE-X
The PCS layer of 1000BASE-X defined in clause 36 of [IEEE802.3] is
based on 8B/10B code.
The PSN-bound NSP function does not modify the received data and is
transparent to auto-negotiation but is responsible to detect
1000BASE-X specific attachment circuit faults such as LOS and sync
loss.
When the CE-bound IWF is in PLOS state or when PLE packets are
received with the L-bit being set, the CE-bound NSP function MAY
disable its transmitter as no appropriate maintenance signal was
defined for 1000BASE-X by IEEE.
4.2.2. 10GBASE-R and 25GBASE-R
The PCS layers of 10GBASE-R defined in clause 49 and 25GBASE-R
defined in clause 107 of [IEEE802.3] are based on a 64B/66B code.
[IEEE802.3] clauses 74 and 108 do define an optional FEC layer, if
present the PSN-bound NSP function MUST terminate the FEC and the CE-
bound NSP function MUST generate the FEC.
The PSN-bound NSP function is also responsible to detect 10GBASE-R
and 25GBASE-R specific attachment circuit faults such as LOS and sync
loss.
The PSN-bound IWF is mapping the scrambled 64B/66B code stream into
the basic PLE payload.
The CE-bound NSP function MUST perform
* PCS code sync
* descrambling
in order to properly
* transform invalid 66B code blocks into proper error control
characters /E/
Gringeri, et al. Expires 9 May 2025 [Page 10]
Internet-Draft PLE November 2024
* insert Local Fault (LF) ordered sets when the CE-bound IWF is in
PLOS state or when PLE packets are received with the L-bit being
set
Note: Invalid 66B code blocks typically are a consequence of the CE-
bound IWF inserting replacement data in case of lost PLE packets, or
if the far-end PSN-bound NSP function did set sync headers to 11 due
to uncorrectable FEC errors.
Before sending the bit stream to the CE, the CE-bound NSP function
MUST also scramble the 64B/66B code stream.
4.2.3. 40GBASE-R, 50GBASE-R and 100GBASE-R
The PCS layers of 40GBASE-R and 100GBASE-R defined in clause 82 and
of 50GBASE-R defined in clause 133 of [IEEE802.3] are based on a
64B/66B code transmitted over multiple lanes.
[IEEE802.3] clauses 74 and 91 do define an optional FEC layer, if
present the PSN-bound NSP function MUST terminate the FEC and the CE-
bound NSP function MUST generate the FEC.
To gain access to the scrambled 64B/66B code stream the PSN-bound NSP
further MUST perform
* block synchronization
* PCS lane de-skew
* PCS lane reordering
The PSN-bound NSP function is also responsible to detect 40GBASE-R,
50GBASE-R and 100GBASE-R specific attachment circuit faults such as
LOS and loss of alignment.
The PSN-bound IWF is mapping the serialized, scrambled 64B/66B code
stream including the alignment markers into the basic PLE payload.
The CE-bound NSP function MUST perform
* PCS code sync
* alignment marker removal
* descrambling
in order to properly
Gringeri, et al. Expires 9 May 2025 [Page 11]
Internet-Draft PLE November 2024
* transform invalid 66B code blocks into proper error control
characters /E/
* insert Local Fault (LF) ordered sets when the CE-bound IWF is in
PLOS state or when PLE packets are received with the L-bit being
set
Note: Invalid 66B code blocks typically are a consequence of the CE-
bound IWF inserting replacement data in case of lost PLE packets, or
if the far-end PSN-bound NSP function did set sync headers to 11 due
to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform
* scrambling of the 64B/66B code
* block distribution
* alignment marker insertion
4.2.4. 200GBASE-R and 400GBASE-R
The PCS layers of 200GBASE-R and 400GBASE-R defined in clause 119 of
[IEEE802.3] are based on a 64B/66B code transcoded to a 256B/257B
code to reduce the overhead and make room for a mandatory FEC.
To gain access to the 64B/66B code stream the PSN-bound NSP further
MUST perform
* alignment lock and de-skew
* PCS Lane reordering and de-interleaving
* FEC decoding
* post-FEC interleaving
* alignment marker removal
* descrambling
* reverse transcoding from 256B/257B to 64B/66B
Further the PSN-bound NSP MUST perform rate compensation and
scrambling before the PSN-bound IWF is mapping the same into the
basic PLE payload.
Gringeri, et al. Expires 9 May 2025 [Page 12]
Internet-Draft PLE November 2024
Rate compensation is applied so that the rate of the 66B encoded bit
stream carried by PLE is 528/544 times the nominal bitrate of the
200GBASE-R or 400GBASE-R at the PMA service interface. X number of
66 byte long rate compensation blocks are inserted every X*20479
number of 66B client blocks. For 200GBASE-R the value of X is 16 and
for 400GBASE-R the value of X is 32. Rate compensation blocks are
special 66B control characters of type 0x00 that can easily be
searched for by the CE-bound IWF in order to remove them.
The PSN-bound NSP function is also responsible to detect 200GBASE-R
and 400GBASE-R specific attachment circuit faults such as LOS and
loss of alignment.
The CE-bound NSP function MUST perform
* PCS code sync
* descrambling
* rate compensation block removal
in order to properly
* transform invalid 66B code blocks into proper error control
characters /E/
* insert Local Fault (LF) ordered sets when the CE-bound IWF is in
PLOS state or when PLE packets are received with the L-bit being
set
Note: Invalid 66B code blocks typically are a consequence of the CE-
bound IWF inserting replacement data in case of lost PLE packets, or
if the far-end PSN-bound NSP function did set sync headers to 11 due
to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform
* transcoding from 64B/66B to 256B/257B
* scrambling
* alignment marker insertion
* pre-FEC distribution
* FEC encoding
Gringeri, et al. Expires 9 May 2025 [Page 13]
Internet-Draft PLE November 2024
* PCS Lane distribution
4.2.5. Energy Efficient Ethernet (EEE)
Section 78 of [IEEE802.3] does define the optional Low Power Idle
(LPI) capability for Ethernet. Two modes are defined
* deep sleep
* fast wake
Deep sleep mode is not compatible with PLE due to the CE ceasing
transmission. Hence there is no support for LPI for 10GBASE-R
services across PLE.
When in fast wake mode the CE transmits /LI/ control code blocks
instead of /I/ control code blocks and therefore PLE is agnostic to
it. For 25GBASE-R and higher services across PLE, LPI is supported
as only fast wake mode is applicable.
4.3. SONET/SDH Services
SONET/SDH services are special cases of the structured bit stream
defined in Section 3.3.4 of [RFC3985].
SDH interfaces are defined in [G.707] and SONET interfaces are
defined in [GR253].
The PSN-bound NSP function does not modify the received data but is
responsible to detect SONET/SDH interface specific attachment circuit
faults such as LOS, LOF and OOF.
Data received by the PSN-bound IWF is mapped into the basic PLE
payload without any awareness of SONET/SDH frames.
When the CE-bound IWF is in PLOS state or when PLE packets are
received with the L-bit being set, the CE-bound NSP function is
responsible for generating the
* MS-AIS maintenance signal defined in clause 6.2.4.1.1 of [G.707]
for SDH services
* AIS-L maintenance signal defined in clause 6.2.1.2 of [GR253] for
SONET services
at client frame boundaries.
Gringeri, et al. Expires 9 May 2025 [Page 14]
Internet-Draft PLE November 2024
4.4. Fibre Channel Services
Fibre Channel services are special cases of the structured bit stream
defined in Section 3.3.4 of [RFC3985].
The T11 technical committee of INCITS has defined several layers for
Fibre Channel. Emulation is operating at the FC-1 layer.
Over time many different Fibre Channel interface types have been
specified with a varying set of characteristics such as optional vs
mandatory FEC and single-lane vs multi-lane transmission.
Speed negotiation is out of scope for this document.
All Fibre Channel services are leveraging the basic PLE payload and
interface specific mechanisms are confined to the respective service
specific NSP functions.
4.4.1. 1GFC, 2GFC, 4GFC and 8GFC
[FC-PI-2] specifies 1GFC and 2GFC. [FC-PI-5] and [FC-PI-5am1] do
define 4GFC and 8GFC.
The PSN-bound NSP function is responsible to detect Fibre Channel
specific attachment circuit faults such as LOS and sync loss.
The PSN-bound IWF is mapping the received 8B/10B code stream as is
directly into the basic PLE payload.
The CE-bound NSP function MUST perform transmission word sync in
order to properly
* replace invalid transmission words with the special character
K30.7
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is
in PLOS state or when PLE packets are received with the L-bit
being set
Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets.
[FC-PI-5am1] does define the use of scrambling for 8GFC, in this case
the CE-bound NSP MUST also perform descrambling before replacing
invalid transmission words or inserting NOS ordered sets. And before
sending the bit stream to the, the CE-bound NSP function MUST
scramble the 8B/10B code stream.
Gringeri, et al. Expires 9 May 2025 [Page 15]
Internet-Draft PLE November 2024
4.4.2. 16GFC and 32GFC
[FC-PI-5] and [FC-PI-5am1] specify 16GFC and define a optional FEC
layer. [FC-PI-6] specifies 32GFC with the FEC layer and transmitter
training signal (TTS) support being mandatory.
If FEC is present it must be indicated via TTS during attachment
circuit bring up. Further the PSN-bound NSP function MUST terminate
the FEC and the CE-bound NSP function must generate the FEC.
The PSN-bound NSP function is responsible to detect Fibre Channel
specific attachment circuit faults such as LOS and sync loss.
The PSN-bound IWF is mapping the received 64B/66B code stream as is
into the basic PLE payload.
The CE-bound NSP function MUST perform
* transmission word sync
* descrambling
in order to properly
* replace invalid transmission words with the error transmission
word 1Eh
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is
in PLOS state or when PLE packets are received with the L-bit
being set
Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets,
or if the far-end PSN-bound NSP function did set sync headers to 11
due to uncorrectable FEC errors.
Before sending the bit stream to the CE, the CE-bound NSP function
MUST also scramble the 64B/66B code stream.
4.4.3. 64GFC and 4-lane 128GFC
[FC-PI-7] specifies 64GFC and [FC-PI-6P] specifies 4-lane 128GFC.
Both specify a mandatory FEC layer. The PSN-bound NSP function MUST
terminate the FEC and the CE-bound NSP function must generate the
FEC.
To gain access to the 64B/66B code stream the PSN-bound NSP further
MUST perform
Gringeri, et al. Expires 9 May 2025 [Page 16]
Internet-Draft PLE November 2024
* alignment lock and de-skew
* Lane reordering and de-interleaving
* FEC decoding
* post-FEC interleaving
* alignment marker removal
* descrambling
* reverse transcoding from 256B/257B to 64B/66B
Further the PSN-bound NSP MUST perform scrambling before the PSN-
bound IWF is mapping the same into the basic PLE payload.
Note : The use of rate compensation is for further study and out of
scope for this document.
The PSN-bound NSP function is also responsible to detect Fibre
Channel specific attachment circuit faults such as LOS and sync loss.
The CE-bound NSP function MUST perform
* transmission word sync
* descrambling
in order to properly
* replace invalid transmission words with the error transmission
word 1Eh
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is
in PLOS state or when PLE packets are received with the L-bit
being set
Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets,
or if the far-end PSN-bound NSP function did set sync headers to 11
due to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform
* transcoding from 64B/66B to 256B/257B
Gringeri, et al. Expires 9 May 2025 [Page 17]
Internet-Draft PLE November 2024
* scrambling
* alignment marker insertion
* pre-FEC distribution
* FEC encoding
* Lane distribution
4.5. OTN Services
OTN services are special cases of the structured bit stream defined
in Section 3.3.4 of [RFC3985].
OTN interfaces are defined in [G.709].
The PSN-bound NSP function MUST terminate the FEC and replace the
OTUk overhead in row 1 columns 8-14 with all-0s fixed stuff which
results in a extended ODUk frame as illustrated in Figure 3. The
frame alignment overhead (FA OH) in row 1 columns 1-7 is kept as it
is.
column #
1 7 8 14 15 3824
+--------+--------+------------------- .. --------------------+
1| FA OH | All-0s | |
+--------+--------+ |
r 2| | |
o | | |
w 3| ODUk overhead | |
# | | |
4| | |
+-----------------+------------------- .. --------------------+
Figure 3: Extended ODUk Frame
The PSN-bound NSP function is also responsible to detect OTUk
specific attachment circuit faults such as LOS, LOF, LOM and AIS.
The PSN-bound IWF is mapping the extended ODUk frame into the byte
aligned PLE payload.
The CE-bound NSP function will recover the ODUk by searching for the
frame alignment overhead in the extended ODUk received from the CE-
bound IWF and generates the FEC.
Gringeri, et al. Expires 9 May 2025 [Page 18]
Internet-Draft PLE November 2024
When the CE-bound IWF is in PLOS state or when PLE packets are
received with the L-bit being set, the CE-bound NSP function is
responsible for generating the ODUk-AIS maintenance signal defined in
clause 16.5.1 of [G.709] at client frame boundaries.
5. PLE Encapsulation Layer
The basic packet format used by PLE is shown in the Figure 4.
+-------------------------------+ -+
| PSN and VPWS Demux | \
| (MPLS/SRv6) | > PSN and VPWS
| | / Demux Headers
+-------------------------------+ -+
| PLE Control Word | \
+-------------------------------+ > PLE Header
| RTP Header | /
+-------------------------------+ --+
| Bit Stream | \
| Payload | > Payload
| | /
+-------------------------------+ --+
Figure 4: PLE Encapsulation Layer
5.1. PSN and VPWS Demultiplexing Headers
This document does not imply any specific technology to be used for
implementing the VPWS demultiplexing and PSN layers.
The total size of a PLE packet for a specific PW MUST NOT exceed the
path MTU between the pair of PEs terminating this PW.
When a MPLS PSN layer is used, a VPWS label provides the
demultiplexing mechanism as described in Section 5.4.2 of [RFC3985].
The PSN tunnel can be a simple best path Label Switched Path (LSP)
established using LDP [RFC5036] or Segment Routing [RFC8402] or a
traffic engineered LSP established using RSVP-TE [RFC3209] or SR-TE
[RFC9256].
When a SRv6 PSN layer is used, a SRv6 service segment identifier
(SID) as defined in [RFC8402] does provide the demultiplexing
mechanism and definitions of Section 6 of [RFC9252] do apply. Both
SRv6 service SIDs with the full IPv6 address format defined in
[RFC8986] and compressed SIDs (C-SIDs) with format defined in
[I-D.draft-ietf-spring-srv6-srh-compression] can be used.
Gringeri, et al. Expires 9 May 2025 [Page 19]
Internet-Draft PLE November 2024
Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are
defined in this document. The behavior procedures are applicable to
both SIDs and C-SIDs.
The H.Encaps.L1 behavior encapsulates a frame received from an IWF in
a IPv6 packet with an segment routing header (SRH). The received
frame becomes the payload of the new IPv6 packet.
* The next header field of the SRH MUST be set to TBA1.
* The push of the SRH MAY be omitted when the SRv6 policy only
contains one segment.
The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1
behavior.
* H.Encaps.L1.Red reduces the length of the SRH by excluding the
first SID in the SRH of the pushed IPv6 header. The first SID is
only placed in the destination address field of the pushed IPv6
header.
* The push of the SRH MAY be omitted when the SRv6 policy only
contains one segment.
Three new "Endpoint with decapsulation and bit-stream cross-connect"
behaviors called End.DX1, End.DX1 with NEXT-CSID and End.DX1 with
REPLACE-CSID are defined in this document. These new behaviors are
variants of End.DX2 defined in [RFC8986] and all have the following
procedures in common.
The End.DX1 SID MUST be the last segment in an SR Policy, and it is
associated with a CE-bound IWF I. When N receives a packet destined
to S and S is a local End.DX1 SID, N does the following:
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the next (Upper-Layer) header of a packet matching a
FIB entry locally instantiated as an End.DX1 SID, N does the
following:
Gringeri, et al. Expires 9 May 2025 [Page 20]
Internet-Draft PLE November 2024
S01. If (Upper-Layer header type == TBA1 (bit-stream) ) {
S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the remaining frame to the IWF I
S04. } Else {
S05. Process as per {{Section 4.1.1 of RFC8986}}
S06. }
5.2. PLE Header
The PLE header MUST contain the PLE control word (4 bytes) and MUST
include a fixed size RTP header [RFC3550]. The RTP header MUST
immediately follow the PLE control word.
5.2.1. PLE Control Word
The format of the PLE control word is in line with the guidance in
[RFC4385] and is shown in Figure 5.
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 0 0|L|R|RSV|FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PLE Control Word
The bits 0..3 of the first nibble are set to 0 to differentiate a
control word or Associated Channel Header (ACH) from an IP packet or
Ethernet frame. The first nibble MUST be set to 0000b to indicate
that this header is a control word as defined in Section 3 of
[RFC4385].
The other fields in the control word are used as defined below:
* L
Set by the PE to indicate that data carried in the payload is
invalid due to an attachment circuit fault. The downstream PE
MUST send appropriate replacement data. The NSP MAY inject an
appropriate native fault propagation signal.
* R
Set by the downstream PE to indicate that the IWF experiences
packet loss from the PSN or a server layer backward fault
indication is present in the NSP. The R bit MUST be cleared by
the PE once the packet loss state or fault indication has cleared.
Gringeri, et al. Expires 9 May 2025 [Page 21]
Internet-Draft PLE November 2024
* RSV
These bits are reserved for future use. This field MUST be set to
zero by the sender and ignored by the receiver.
* FRG
These bits MUST be set to zero by the sender and ignored by the
receiver as PLE does not use payload fragmentation.
* LEN
In accordance to Section 3 of [RFC4385] the length field MUST
always be set to zero as there is no padding added to the PLE
packet. To detect malformed packets the default, preconfigured or
signaled payload size MUST be assumed.
* Sequence number
The sequence number field is used to provide a common PW
sequencing function as well as detection of lost packets. It MUST
be generated in accordance with the rules defined in Section 5.1
of [RFC3550] and MUST be incremented with every PLE packet being
sent.
5.2.2. RTP Header
The RTP header MUST be included and is used for explicit transfer of
timing information. The RTP header is purely a formal reuse and RTP
mechanisms, such as header extensions, contributing source (CSRC)
list, padding, RTP Control Protocol (RTCP), RTP header compression,
Secure Realtime Transport Protocol (SRTP), etc., are not applicable
to PLE VPWS.
The format of the RTP header is as shown in Figure 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTP Header
Gringeri, et al. Expires 9 May 2025 [Page 22]
Internet-Draft PLE November 2024
* V: Version
The version field MUST be set to 2.
* P: Padding
The padding flag MUST be set to zero by the sender and ignored by
the receiver.
* X: Header extension
The X bit MUST be set to zero by sender and ignored by receiver.
* CC: CSRC count
The CC field MUST be set to zero by the sender and ignored by the
receiver.
* M: Marker
The M bit MUST be set to zero by the sender and ignored by the
receiver.
* PT: Payload type
A PT value MUST be allocated from the range of dynamic values
defined in Section 6 of [RFC3551] for each direction of the VPWS.
The same PT value MAY be reused both for direction and between
different PLE VPWS.
* Sequence number
The Sequence number in the RTP header MUST be equal to the
sequence number in the PLE control word. The sequence number of
the RTP header MAY be used to extend the sequence number of the
PLE control word from 16 to 32 bits. If so, the initial value of
the RTP sequence number MUST be 0 and incremented whenever the PLE
control word sequence number cycles through from 0xFFFF to 0x0000.
* Timestamp
Timestamp values are used in accordance with the rules established
in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the
clock used for generating timestamps MUST be 125 MHz based on a
the common clock I. For bit-streams above 200 Gbps the frequency
MUST be 250 MHz.
* SSRC: Synchronization source
Gringeri, et al. Expires 9 May 2025 [Page 23]
Internet-Draft PLE November 2024
The SSRC field MAY be used for detection of misconnections.
6. PLE Payload Layer
A bit-stream is mapped into a PLE packet with a fixed payload size
which MUST be defined during VPWS setup, MUST be the same in both
directions of the VPWS and MUST remain unchanged for the lifetime of
the VPWS.
All PLE implementations MUST be capable of supporting the default
payload size of 1024 bytes.
6.1. Basic Payload
The PLE payload is filled with incoming bits of the bit-stream
starting from the most significant to the least significant bit
without considering any structure of the bit-stream.
6.2. Byte aligned Payload
The PLE payload is filled in a byte aligned manner, where the order
of the payload bytes corresponds to their order on the attachment
circuit. Consecutive bits coming from the attachment circuit fill
each payload byte starting from most significant bit to least
significant. The PLE payload size MUST be an integer number of
bytes.
7. PLE Operation
7.1. Common Considerations
A PLE VPWS can be established using manual configuration or
leveraging mechanisms of a signaling protocol.
Furthermore emulation of bit-stream signals using PLE is only
possible when the two attachment circuits of the VPWS are of the same
service type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE
payload type and payload size. This can be ensured via manual
configuration or via the mechanisms of a signaling protocol.
PLE related control protocol extensions to LDP [RFC8077] or EVPN-VPWS
[RFC8214] are out of scope for this document.
Extensions for EVPN-VPWS are proposed in
[I-D.draft-schmutzer-bess-bitstream-vpws-signalling] and for LDP in
[I-D.draft-schmutzer-pals-ple-signaling].
Gringeri, et al. Expires 9 May 2025 [Page 24]
Internet-Draft PLE November 2024
7.2. PLE IWF Operation
7.2.1. PSN-bound Encapsulation Behavior
After the VPWS is set up, the PSN-bound IWF does perform the
following steps:
* Packetize the data received from the CE is into a fixed size PLE
payloads
* Add PLE control word and RTP header with sequence numbers, flags
and timestamps properly set
* Add the VPWS demultiplexer and PSN headers
* Transmit the resulting packets over the PSN
* Set L bit in the PLE control word whenever attachment circuit
detects a fault
* Set R bit in the PLE control word whenever the local CE-bound IWF
is in packet loss state
7.2.2. CE-bound Decapsulation Behavior
The CE-bound IWF is responsible for removing the PSN and VPWS
demultiplexing headers, PLE control word and RTP header from the
received packet stream and sending the bit-stream out via the local
attachment circuit.
A de-jitter buffer MUST be implemented where the PLE packets are
stored upon arrival. The size of this buffer SHOULD be locally
configurable to allow accommodation of specific PSN packet delay
variation expected.
The CE-bound IWF SHOULD use the sequence number in the control word
to detect lost and misordered packets. It MAY use the sequence
number in the RTP header for the same purposes. The CE-bound IWF MAY
support re-ordering of packets received out of order. If the CE-
bound IWF does not support re-ordering it MUST drop the misordered
packets.
The payload of a lost or dropped packet MUST be replaced with
equivalent amount of replacement data. The contents of the
replacement data MAY be locally configurable. By default, all PLE
implementations MUST support generation of "0xAA" as replacement
data. The alternating sequence of 0s and 1s of the "0xAA" pattern
does ensure clock synchronization is maintained and for 64B/66B code
Gringeri, et al. Expires 9 May 2025 [Page 25]
Internet-Draft PLE November 2024
based services no invalid sync headers are generated. While sending
out the replacement data, the IWF will apply a holdover mechanism to
maintain the clock.
Whenever the VPWS is not operationally up, the CE-bound NSP function
MUST inject the appropriate native downstream fault indication
signal.
Whenever a VPWS comes up, the CE-bound IWF enters the intermediate
state, will start receiving PLE packets and will store them in the
jitter buffer. The CE-bound NSP function will continue to inject the
appropriate native downstream fault indication signal until a pre-
configured number of payload s stored in the jitter buffer.
After the pre-configured amount of payload is present in the jitter
buffer the CE-bound IWF transitions to the normal operation state and
the content of the jitter buffer is streamed out to the CE in
accordance with the required clock. In this state the CE-bound IWF
MUST perform egress clock recovery.
The recovered clock MUST comply with the jitter and wander
requirements applicable to the type of attachment circuit, specified
in:
* [G.825] and [G.823] for SDH
* [GR253] for SONET
* [G.8261] for synchronous Ethernet
* [G.8251] for OTN
Whenever the L bit is set in the PLE control word of a received PLE
packet the CE-bound NSP function SHOULD inject the appropriate native
downstream fault indication signal instead of streaming out the
payload.
If the CE-bound IWF detects loss of consecutive packets for a pre-
configured amount of time (default is 1 millisecond), it enters
packet loss (PLOS) state and a corresponding defect is declared.
Gringeri, et al. Expires 9 May 2025 [Page 26]
Internet-Draft PLE November 2024
If the CE-bound IWF detects a packet loss ratio (PLR) above a
configurable signal-degrade (SD) threshold for a configurable amount
of consecutive 1-second intervals, it enters the degradation (DEG)
state and a corresponding defect is declared. The SD-PLR threshold
can be defined as percentage with the default being 15% or absolute
packet count for finer granularity for higher rate interfaces.
Possible values for consecutive intervals are 2..10 with the default
7.
While the PLOS defect is declared the CE-bound NSP function SHOULD
inject the appropriate native downstream fault indication signal.
Also the PSN-bound IWF SHOULD set the R bit in the PLE control word
of every packet transmitted.
The CE-bound IWF does change from the PLOS to normal state after the
pre-configured amount of payload has been received similarly to the
transition from intermediate to normal state.
Whenever the R bit is set in the PLE control word of a received PLE
packet the PLE performance monitoring statistics SHOULD get updated.
7.3. PLE Performance Monitoring
Attachment circuit performance monitoring SHOULD be provided by the
NSP. The performance monitors are service specific, documented in
related specifications and beyond the scope of this document.
The PLE IWF SHOULD provide functions to monitor the network
performance to be inline with expectations of transport network
operators.
The near-end performance monitors defined for PLE are as follows:
* ES-PLE : PLE Errored Seconds
* SES-PLE : PLE Severely Errored Seconds
* UAS-PLE : PLE Unavailable Seconds
Each second with at least one packet lost or a PLOS/DEG defect SHALL
be counted as ES-PLE. Each second with a PLR greater than 15% or a
PLOS/DEG defect SHALL be counted as SES-PLE.
UAS-PLE SHALL be counted after a configurable number of consecutive
SES-PLE have been observed, and no longer counted after a
configurable number of consecutive seconds without SES-PLE have been
observed. Default value for each is 10 seconds.
Gringeri, et al. Expires 9 May 2025 [Page 27]
Internet-Draft PLE November 2024
Once unavailability is detected, ES and SES counts SHALL be inhibited
up to the point where the unavailability was started. Once
unavailability is removed, ES and SES that occurred along the
clearing period SHALL be added to the ES and SES counts.
A PLE far-end performance monitor is providing insight into the CE-
bound IWF at the far end of the PSN. The statistics are based on the
PLE-RDI indication carried in the PLE control word via the R bit.
The PLE VPWS performance monitors are derived from the definitions in
accordance with [G.826]
Performance monitoring data MUST be provided by the management
interface and SHOULD be provided by a YANG model. The YANG model
specification is out of scope for this document.
7.4. PLE Fault Management
Attachment circuit faults applicable to PLE are detected by the NSP,
are service specific and are documented in relevant section of
Section 4.
The two PLE faults, PLOS and DEG are detected by the IWF.
Faults MUST be time stamped as they are declared and cleared and
fault related information MUST be provided by the management
interface and SHOULD be provided by a YANG model. The YANG model
specification is out of scope for this document.
8. QoS and Congestion Control
The PSN carrying PLE VPWS may be subject to congestion. Congestion
considerations for PWs are described in Section 6.5 of [RFC3985].
PLE VPWS represent inelastic constant bit-rate (CBR) flows that
cannot respond to congestion in a TCP-friendly manner as described in
[RFC2914] and are sensitive to jitter, packet loss and packets
received out of order.
The PSN providing connectivity between PE devices of a PLE VPWS has
to ensure low jitter and low loss. The exact mechanisms used are
beyond the scope of this document and may evolve over time. Possible
options, but not exhaustively, are a Diffserv-enabled [RFC2475] PSN
with a per domain behavior [RFC3086] supporting Expedited Forwarding
[RFC3246]. Traffic-engineered paths through the PSN with bandwidth
reservation and admission control applied. Or capacity over-
provisioning.
Gringeri, et al. Expires 9 May 2025 [Page 28]
Internet-Draft PLE November 2024
9. Security Considerations
As PLE is leveraging VPWS as transport mechanism, the security
considerations described [RFC3985] are applicable.
PLE does not enhance or detract from the security performance of the
underlying PSN. It relies upon the PSN mechanisms for encryption,
integrity, and authentication whenever required.
The PSN is assumed to be trusted and secure. Considerations about
the MPLS core network outlined in [RFC4381] are applicable.
For MPLS based PSNs, one of the requirements for protecting the data
plane is that the MPLS packets be accepted only from valid
interfaces. For a PE, valid interfaces comprise links from other
routers in the PE's own AS. For an ASBR, valid interfaces comprise
links from other routers in the ASBR's own AS, and links from other
ASBRs in ASes that have instances of a given PLE PWs. It is
especially important in the case of multi-AS PLE PWs that one accepts
PLE packets only from valid interfaces.
When a Segment Routing (SR) based PSN is used (MPLS or SRv6) the
considerations in Section 8 of [RFC8402] and Section 9.3 of [RFC9252]
are applicable.
PLE PWs share susceptibility to a number of pseudowire-layer attacks
and will use whatever mechanisms for confidentiality, integrity, and
authentication that are developed for general PWs. These methods are
beyond the scope of this document.
Random initialization of sequence numbers, in both the control word
and the RTP header, makes known-plaintext attacks more difficult.
Misconnection detection using the SSRC of the RTP header can increase
the resilience to misconfiguration and some types of denial-of-
service (DoS) attacks. A randomly chosen expected SSRC value does
decrease the chance of a spoofing attack being successful. Control
plane mechanisms for signaling the expected SSRC value are described
in [I-D.draft-schmutzer-bess-bitstream-vpws-signalling] and
[I-D.draft-schmutzer-pals-ple-signaling].
A data plane attack may force PLE packets to be dropped, re-ordered
or delayed beyond the limit of the CE-bound IWF's dejitter buffer
leading to either degradation or service disruption. Considerations
outlined in [RFC9055] are a good reference.
Gringeri, et al. Expires 9 May 2025 [Page 29]
Internet-Draft PLE November 2024
Clock synchronization leveraging PTP is sensitive to Packet Delay
Variation (PDV) and vulnerable to various threads and attack vectors.
Considerations outlined in [RFC7384] should be taken into account.
10. IANA Considerations
10.1. Bit-stream Next Header Type
This document introduces a new value to be used in the next header
field of an IPv6 header or any extension header indicating that the
payload is a emulated bit-stream. IANA is requested to assign the
following from the "Assigned Internet Protocol Numbers" registry (see
https://www.iana.org/assignments/protocol-numbers/).
+=========+=========+============+================+===========+
| Decimal | Keyword | Protocol | IPv6 Extension | Reference |
| | | | Header | |
+=========+=========+============+================+===========+
| TBA1 | BIT-EMU | Bit-stream | Y | this |
| | | Emulation | | document |
+---------+---------+------------+----------------+-----------+
Table 1
10.2. SRv6 Endpoint Behaviors
This document introduces three new SRv6 Endpoint behaviors. IANA is
requested to assign identifier values in the "SRv6 Endpoint
Behaviors" sub-registry under "Segment Routing Parameters" registry.
+=======+========+===========================+===============+
| Value | Hex | Endpoint Behavior | Reference |
+=======+========+===========================+===============+
| 158 | 0x009E | End.DX1 | this document |
+-------+--------+---------------------------+---------------+
| 159 | 0x009F | End.DX1 with NEXT-CSID | this document |
+-------+--------+---------------------------+---------------+
| 160 | 0x00A0 | End.DX1 with REPLACE-CSID | this document |
+-------+--------+---------------------------+---------------+
Table 2
11. Acknowledgements
The authors would like to thank all reviewers, contributors and the
working group for reviewing this document and providing useful
comments and suggestions.
Gringeri, et al. Expires 9 May 2025 [Page 30]
Internet-Draft PLE November 2024
12. References
12.1. Normative References
[I-D.draft-ietf-spring-srv6-srh-compression]
Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding", Work in
Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-19, 3 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-19>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/rfc/rfc3551>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/rfc/rfc9252>.
12.2. Informative References
[FC-PI-2] INCITS, "Information Technology - Fibre Channel Physical
Interfaces - 2 (FC-PI-2)", 2006,
<https://webstore.ansi.org/standards/incits/
incits4042006>.
[FC-PI-5] INCITS, "Information Technology - Fibre Channel - Physical
Interface-5 (FC-PI-5)", 2011,
<https://webstore.ansi.org/standards/incits/
incits4792011>.
Gringeri, et al. Expires 9 May 2025 [Page 31]
Internet-Draft PLE November 2024
[FC-PI-5am1]
INCITS, "Information Technology - Fibre Channel - Physical
Interface - 5/Amendment 1 (FC-PI-5/AM1)", 2016,
<https://webstore.ansi.org/standards/incits/
incits4792011am12016>.
[FC-PI-6] INCITS, "Information Technology - Fibre Channel - Physical
Interface - 6 (FC-PI-6)", 2015,
<https://webstore.ansi.org/standards/incits/
incits5122015>.
[FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
Interface - 6P (FC-PI-6P)", 2016,
<https://webstore.ansi.org/standards/incits/
incits5332016>.
[FC-PI-7] INCITS, "Information Technology – Fibre Channel - Physical
Interfaces - 7 (FC-PI-7)", 2021,
<https://webstore.ansi.org/standards/iso/
isoiec141651472021>.
[G.707] International Telecommunication Union (ITU), "Network node
interface for the synchronous digital hierarchy (SDH)",
January 2007, <https://www.itu.int/rec/T-REC-G.707>.
[G.709] International Telecommunication Union (ITU), "Interfaces
for the optical transport network", June 2020,
<https://www.itu.int/rec/T-REC-G.709>.
[G.823] International Telecommunication Union (ITU), "The control
of jitter and wander within digital networks which are
based on the 2048 kbit/s hierarchy", March 2000,
<https://www.itu.int/rec/T-REC-G.823>.
[G.825] International Telecommunication Union (ITU), "The control
of jitter and wander within digital networks which are
based on the synchronous digital hierarchy (SDH)", March
2000, <https://www.itu.int/rec/T-REC-G.825>.
[G.8251] International Telecommunication Union (ITU), "The control
of jitter and wander within the optical transport network
(OTN)", November 2022,
<https://www.itu.int/rec/T-REC-G.8251>.
Gringeri, et al. Expires 9 May 2025 [Page 32]
Internet-Draft PLE November 2024
[G.826] International Telecommunication Union (ITU), "End-to-end
error performance parameters and objectives for
international, constant bit-rate digital paths and
connections", December 2002,
<https://www.itu.int/rec/T-REC-G.826>.
[G.8261] International Telecommunication Union (ITU), "Timing and
synchronization aspects in packet networks", August 2019,
<https://www.itu.int/rec/T-REC-G.8261>.
[G.8261.1] International Telecommunication Union (ITU), "Packet delay
variation network limits applicable to packet-based
methods (Frequency synchronization)", February 2012,
<https://www.itu.int/rec/T-REC-G.8261.1>.
[G.8262] International Telecommunication Union (ITU), "Timing
characteristics of synchronous equipment slave clock",
November 2018, <https://www.itu.int/rec/T-REC-G.8262>.
[G.8265.1] International Telecommunication Union (ITU), "Precision
time protocol telecom profile for frequency
synchronization", November 2022,
<https://www.itu.int/rec/T-REC-G.8265.1>.
[GR253] Telcordia, "SONET Transport Systems - Common Generic
Criteria", October 2009.
[I-D.draft-schmutzer-bess-bitstream-vpws-signalling]
Gringeri, S., Whittaker, J., Schmutzer, C., Vasudevan, B.,
and P. Brissette, "Ethernet VPN Signalling Extensions for
Bit-stream VPWS", Work in Progress, Internet-Draft, draft-
schmutzer-bess-bitstream-vpws-signalling-02, 18 October
2024, <https://datatracker.ietf.org/doc/html/draft-
schmutzer-bess-bitstream-vpws-signalling-02>.
[I-D.draft-schmutzer-pals-ple-signaling]
Schmutzer, C., "LDP Extensions to Support Private Line
Emulation (PLE)", Work in Progress, Internet-Draft, draft-
schmutzer-pals-ple-signaling-02, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-schmutzer-
pals-ple-signaling-02>.
[IEEE802.3]
IEEE, "IEEE Standard for Ethernet", May 2022,
<https://standards.ieee.org/ieee/802.3/10422/>.
Gringeri, et al. Expires 9 May 2025 [Page 33]
Internet-Draft PLE November 2024
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/rfc/rfc2914>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, DOI 10.17487/RFC3086,
April 2001, <https://www.rfc-editor.org/rfc/rfc3086>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/rfc/rfc3209>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/rfc/rfc3246>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/rfc/rfc3550>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/rfc/rfc3711>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/rfc/rfc3985>.
Gringeri, et al. Expires 9 May 2025 [Page 34]
Internet-Draft PLE November 2024
[RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation
of Time Division Multiplexed (TDM) Circuits over Packet
Switching Networks", RFC 4197, DOI 10.17487/RFC4197,
October 2005, <https://www.rfc-editor.org/rfc/rfc4197>.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4381,
DOI 10.17487/RFC4381, February 2006,
<https://www.rfc-editor.org/rfc/rfc4381>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/rfc/rfc4385>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/rfc/rfc4448>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
<https://www.rfc-editor.org/rfc/rfc4553>.
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP)",
RFC 4842, DOI 10.17487/RFC4842, April 2007,
<https://www.rfc-editor.org/rfc/rfc4842>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/rfc/rfc4875>.
[RFC4906] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed.,
"Transport of Layer 2 Frames Over MPLS", RFC 4906,
DOI 10.17487/RFC4906, June 2007,
<https://www.rfc-editor.org/rfc/rfc4906>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/rfc/rfc5036>.
Gringeri, et al. Expires 9 May 2025 [Page 35]
Internet-Draft PLE November 2024
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic
Associated Channel (G-ACh) Advertisement Protocol",
RFC 7212, DOI 10.17487/RFC7212, June 2014,
<https://www.rfc-editor.org/rfc/rfc7212>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/rfc/rfc7384>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/rfc/rfc792>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/rfc/rfc8077>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/rfc/rfc8214>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/rfc/rfc9055>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
Contributors
Andreas Burk
1&1 Versatel
Email: andreas.burk@magenta.de
Faisal Dada
AMD
Email: faisal.dada@amd.com
Gringeri, et al. Expires 9 May 2025 [Page 36]
Internet-Draft PLE November 2024
Gerald Smallegange
Ciena Corporation
Email: gsmalleg@ciena.com
Erik van Veelen
Aimvalley
Email: erik.vanveelen@aimvalley.com
Luca Della Chiesa
Cisco Systems, Inc.
Email: ldellach@cisco.com
Nagendra Kumar Nainar
Cisco Systems, Inc.
Email: naikumar@cisco.com
Carlos Pignataro
North Carolina State University
Email: cmpignat@ncsu.edu
Authors' Addresses
Steven Gringeri
Verizon
Email: steven.gringeri@verizon.com
Jeremy Whittaker
Verizon
Email: jeremy.whittaker@verizon.com
Nicolai Leymann
Deutsche Telekom
Email: N.Leymann@telekom.de
Christian Schmutzer (editor)
Cisco Systems, Inc.
Email: cschmutz@cisco.com
Gringeri, et al. Expires 9 May 2025 [Page 37]
Internet-Draft PLE November 2024
Chris Brown
Ciena Corporation
Email: cbrown@ciena.com
Gringeri, et al. Expires 9 May 2025 [Page 38]