rfc9801.original   rfc9801.txt 
Network Working Group S. Gringeri Internet Engineering Task Force (IETF) S. Gringeri
Internet-Draft J. Whittaker Request for Comments: 9801 J. Whittaker
Intended status: Standards Track Verizon Category: Standards Track Verizon
Expires: 16 August 2025 N. Leymann ISSN: 2070-1721 N. Leymann
Deutsche Telekom Deutsche Telekom
C. Schmutzer, Ed. C. Schmutzer, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
C. Brown C. Brown
Ciena Corporation Ciena Corporation
12 February 2025 June 2025
Private Line Emulation over Packet Switched Networks Private Line Emulation over Packet Switched Networks
draft-ietf-pals-ple-15
Abstract Abstract
This document expands the applicability of virtual private wire This document expands the applicability of Virtual Private Wire
services (VPWS) bit-stream payloads beyond Time Division Multiplexing Service (VPWS) bit-stream payloads beyond Time Division Multiplexing
(TDM) signals and provides pseudowire transport with complete signal (TDM) signals and provides pseudowire transport with complete signal
transparency over packet switched networks (PSN). transparency over Packet Switched Networks (PSNs).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 16 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9801.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 1. Introduction and Motivation
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation
3. Terminology and Reference Model . . . . . . . . . . . . . . . 4 3. Terminology and Reference Models
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Terminology
3.2. Reference Models . . . . . . . . . . . . . . . . . . . . 7 3.2. Reference Models
4. Emulated Services . . . . . . . . . . . . . . . . . . . . . . 9 4. Emulated Services
4.1. Generic PLE Service . . . . . . . . . . . . . . . . . . . 9 4.1. Generic PLE Service
4.2. Ethernet services . . . . . . . . . . . . . . . . . . . . 9 4.2. Ethernet Services
4.2.1. 1000BASE-X . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. 1000BASE-X
4.2.2. 10GBASE-R and 25GBASE-R . . . . . . . . . . . . . . . 10 4.2.2. 10GBASE-R and 25GBASE-R
4.2.3. 40GBASE-R, 50GBASE-R and 100GBASE-R . . . . . . . . . 11 4.2.3. 40GBASE-R, 50GBASE-R, and 100GBASE-R
4.2.4. 200GBASE-R and 400GBASE-R . . . . . . . . . . . . . . 12 4.2.4. 200GBASE-R and 400GBASE-R
4.2.5. Energy Efficient Ethernet (EEE) . . . . . . . . . . . 14 4.2.5. Energy Efficient Ethernet (EEE)
4.3. SONET/SDH Services . . . . . . . . . . . . . . . . . . . 14 4.3. SONET/SDH Services
4.4. Fibre Channel Services . . . . . . . . . . . . . . . . . 15 4.4. Fibre Channel Services
4.4.1. 1GFC, 2GFC, 4GFC and 8GFC . . . . . . . . . . . . . . 15 4.4.1. 1GFC, 2GFC, 4GFC, and 8GFC
4.4.2. 16GFC . . . . . . . . . . . . . . . . . . . . . . . . 16 4.4.2. 16GFC
4.4.3. 32GFC and 4-lane 128GFC . . . . . . . . . . . . . . . 17 4.4.3. 32GFC and 4-Lane 128GFC
4.4.4. 64GFC . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.4. 64GFC
4.5. OTN Services . . . . . . . . . . . . . . . . . . . . . . 19 4.5. OTN Services
5. PLE Encapsulation Layer . . . . . . . . . . . . . . . . . . . 20 5. PLE Encapsulation Layer
5.1. PSN and VPWS Demultiplexing Headers . . . . . . . . . . . 20 5.1. PSN and VPWS Demultiplexing Headers
5.1.1. New SRv6 Behaviors . . . . . . . . . . . . . . . . . 21 5.1.1. New SRv6 Behaviors
5.2. PLE Header . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. PLE Header
5.2.1. PLE Control Word . . . . . . . . . . . . . . . . . . 22 5.2.1. PLE Control Word
5.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 23 5.2.2. RTP Header
6. PLE Payload Layer . . . . . . . . . . . . . . . . . . . . . . 25 6. PLE Payload Layer
6.1. Basic Payload . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Basic Payload
6.2. Byte aligned Payload . . . . . . . . . . . . . . . . . . 25 6.2. Byte-Aligned Payload
7. PLE Operation . . . . . . . . . . . . . . . . . . . . . . . . 25 7. PLE Operation
7.1. Common Considerations . . . . . . . . . . . . . . . . . . 26 7.1. Common Considerations
7.2. PLE IWF Operation . . . . . . . . . . . . . . . . . . . . 26 7.2. PLE IWF Operation
7.2.1. PSN-bound Encapsulation Behavior . . . . . . . . . . 26 7.2.1. PSN-Bound Encapsulation Behavior
7.2.2. CE-bound Decapsulation Behavior . . . . . . . . . . . 26 7.2.2. CE-Bound Decapsulation Behavior
7.3. PLE Performance Monitoring . . . . . . . . . . . . . . . 28 7.3. PLE Performance Monitoring
7.4. PLE Fault Management . . . . . . . . . . . . . . . . . . 29 7.4. PLE Fault Management
8. QoS and Congestion Control . . . . . . . . . . . . . . . . . 30 8. QoS and Congestion Control
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10. IANA Considerations
10.1. Bit-stream Next Header Type . . . . . . . . . . . . . . 31 10.1. Bit-Stream Next Header Type
10.2. SRv6 Endpoint Behaviors . . . . . . . . . . . . . . . . 31 10.2. SRv6 Endpoint Behaviors
11. References
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.2. Informative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 32 Acknowledgements
12.2. Informative References . . . . . . . . . . . . . . . . . 35 Contributors
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction and Motivation 1. Introduction and Motivation
This document describes a method called Private Line Emulation (PLE) This document describes a method called Private Line Emulation (PLE)
for encapsulating not only Time Division Multiplexing (TDM) signals for encapsulating not only Time Division Multiplexing (TDM) signals
as bit-stream Virtual Private Wire Service (VPWS) over Packet as bit-stream Virtual Private Wire Service (VPWS) over Packet
Switched Networks (PSN). In this regard, it complements methods Switched Networks (PSN). In this regard, it complements methods
described in [RFC4553]. described in [RFC4553].
This emulation suits applications, where carrying Protocol Data Units This emulation suits applications, where carrying Protocol Data Units
(PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical (PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical
layer signal transparency is required and data or framing structure layer signal transparency is required and data or framing structure
interpretation of the Provider Edge (PE) would be counterproductive. interpretation of the Provider Edge (PE) would be counterproductive.
One example of such case is two Ethernet connected Customer Edge (CE) One example of such case is two Ethernet-connected Customer Edge (CE)
devices and the need for Synchronous Ethernet [G.8261] operation devices and the need for Synchronous Ethernet operation (see
between them without the intermediate PE devices interfering or [G.8261]) between them without the intermediate PE devices
addressing concerns about Ethernet control protocol transparency for interfering or addressing concerns about Ethernet control protocol
PDU based carrier Ethernet services, beyond the behavior definitions transparency for PDU-based carrier Ethernet services, beyond the
of Metro Ethernet Forum (MEF) specifications. behavior definitions of MEF Forum (MEF) specifications.
Another example would be a Storage Area Networking (SAN) extension Another example would be a Storage Area Networking (SAN) extension
between two data centers. Operating at a bit-stream level allows for between two data centers. Operating at a bit-stream level allows for
a connection between Fibre Channel switches without interfering with a connection between Fibre Channel switches without interfering with
any of the Fibre Channel protocol mechanisms defined by [T11]. any of the Fibre Channel protocol mechanisms defined by [T11].
Also, SONET/SDH add/drop multiplexers or cross-connects can be Also, SONET/SDH (Synchronous Optical Network (SONET) / Synchronous
interconnected without interfering with the multiplexing structures Digital Hierarchy (SDH)) add/drop multiplexers or cross-connects can
and networks mechanisms. This is a key distinction to Circuit be interconnected without interfering with the multiplexing
Emulation over Packet (CEP) defined in [RFC4842] where demultiplexing structures and networks mechanisms. This is a key distinction to
and multiplexing is desired in order to operate per SONET Synchronous Circuit Emulation over Packet (CEP) defined in [RFC4842] where
Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual multiplexing and demultiplexing is desired in order to operate per
Container (VC). Said in another way, PLE does provide an independent SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT)
layer network underneath the SONET/SDH layer network, whereas CEP or SDH Virtual Container (VC). In other words, PLE provides an
does operate at the same level and peer with the SONET/SDH layer independent layer network underneath the SONET/SDH layer network,
network. whereas CEP operates at the same level and peer with the SONET/SDH
layer network.
The mechanisms described in this document follow principles similar The mechanisms described in this document follow principles similar
to Structure-Agnostic Time Division Multiplexing (TDM) over Packet to Structure-Agnostic TDM over Packet (SAToP) (defined in [RFC4553]).
(SAToP) defined in [RFC4553]. The applicability is expanded beyond The applicability is expanded beyond the narrow set of Plesiochronous
the narrow set of Plesiochronous Digital Hierarchy (PDH) interfaces Digital Hierarchy (PDH) interfaces (T1, E1, T3, and E3) to allow the
(T1, E1, T3 and E3) to allow the transport of signals from many transport of signals from many different technologies such as
different technologies such as Ethernet, Fibre Channel, SONET/SDH Ethernet, Fibre Channel, SONET/SDH ([GR253] / [G.707]), and OTN
[GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are [G.709] at gigabit speeds. The signals are treated as bit-stream
treated as bit-stream payload which was defined in the Pseudo Wire payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge
Emulation Edge-to-Edge (PWE3) architecture in [RFC3985] sections (PWE3) architecture in Sections 3.3.3 and 3.3.4 of [RFC3985].
3.3.3 and 3.3.4.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology and Reference Model 3. Terminology and Reference Models
3.1. Terminology 3.1. Terminology
* ACH - Associated Channel Header [RFC7212] 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 [ATIS-0900105.09.2013]
* CBR - Constant Bit Rate
* CE - Customer Edge AIS: Alarm Indication Signal
* CEP - Circuit Emulation over Packet [RFC4842] AIS-L: Line AIS
* CSRC - Contributing SouRCe [RFC3550] MS-AIS: Multiplex Section AIS
* DEG - Degradation BITS: Building Integrated Timing Supply [ATIS-0900105.09.2013]
* ES - Errored Second CBR: Constant Bit Rate
* FEC - Forward Error Correction CE: Customer Edge
* ICMP - Internet Control Message Protocol [RFC4443] CEP: Circuit Emulation over Packet [RFC4842]
* IEEE - Institute of Electrical and Electronics Engineers
* INCITS - InterNational Committee for Information Technology CSRC: Contributing Source [RFC3550]
Standards
* IWF - InterWorking Function DEG: Degradation
* LDP - Label Distribution Protocol [RFC5036], [RFC8077] ES: Errored Second
* LF - Local Fault FEC: Forward Error Correction
* LOF - Loss Of Frame ICMP: Internet Control Message Protocol [RFC4443]
* LOM - Loss Of Multiframe IEEE: Institute of Electrical and Electronics Engineers
* LOS - Loss Of Signal INCITS: INternational Committee for Information Technology Standards
* LPI - Low Power Idle IWF: Interworking Function
* LSP - Label Switched Path LDP: Label Distribution Protocol [RFC5036], [RFC8077]
* MEF - Metro Ethernet Forum LF: Local Fault
* MPLS - Multi Protocol Label Switching [RFC3031] LOF: Loss Of Frame
* NOS - Not Operational LOM: Loss Of Multiframe
* NSP - Native Service Processor [RFC3985] LOS: Loss Of Signal
* ODUk - Optical Data Unit k LPI: Low Power Idle
* OTN - Optical Transport Network LSP: Label Switched Path
* OTUk - Optical Transport Unit k MEF: MEF Forum
* PCS - Physical Coding Sublayer MPLS: Multiprotocol Label Switching [RFC3031]
* PDH - Plesiochronous Digital Hierarchy NOS: Not Operational
* PDV - Packet Delay Variation NSP: Native Service Processing [RFC3985]
* PE - Provider Edge ODUk: Optical Data Unit k
* PLE - Private Line Emulation OTN: Optical Transport Network
* PLOS - Packet Loss Of Signal OTUk: Optical Transport Unit k
* PLR - Packet Loss Ratio PCS: Physical Coding Sublayer
* PMA - Physical Medium Attachment
* PMD - Physical Medium Dependent PDV: Packet Delay Variation
* PSN - Packet Switched Network PE: Provider Edge
* PTP - Precision Time Protocol PLE: Private Line Emulation
* PW - Pseudowire [RFC3985] PLOS: Packet Loss Of Signal
* PWE3 - Pseudo Wire Emulation Edge-to-Edge [RFC3985] PLR: Packet Loss Rate
* P2P - Point-to-Point PMA: Physical Medium Attachment
* QOS - Quality Of Service PMD: Physical Medium Dependent
* RDI - Remote Defect Indication PSN: Packet Switched Network
* RSVP-TE - Resource Reservation Protocol Traffic Engineering PTP: Precision Time Protocol
[RFC4875]
* RTCP - RTP Control Protocol [RFC3550] PW: Pseudowire [RFC3985]
* RTP - Realtime Transport Protocol [RFC3550] PWE3: Pseudo Wire Emulation Edge-to-Edge [RFC3985]
* SAN - Storage Area Network RDI: Remote Defect Indication
* SAToP - Structure-Agnostic Time Division Multiplexing (TDM) over RSVP-TE: Resource Reservation Protocol Traffic Engineering [RFC4875]
Packet [RFC4553]
* SD - Signal Degrade RTCP: RTP Control Protocol [RFC3550]
* SES - Severely Errored Second RTP: Real-time Transport Protocol [RFC3550]
* SDH - Synchronous Digital Hierarchy SD: Signal Degrade
* SID - Segment Identifier [RFC8402] SES: Severely Errored Seconds
* SPE - Synchronous Payload Envelope SDH: Synchronous Digital Hierarchy
* SR - Segment Routing [RFC8402] SID: Segment Identifier [RFC8402]
* SRH - Segment Routing Header [RFC8754] SR: Segment Routing [RFC8402]
* SRTP - Secure Realtime Transport Protocol [RFC3711] SRH: Segment Routing Header [RFC8754]
* SRv6 - Segment Routing over IPv6 Dataplane [RFC8986] SRTP: Secure Real-time Transport Protocol [RFC3711]
* SSRC - Synchronization SouRCe [RFC3550]
* SONET - Synchronous Optical Network SRv6: Segment Routing over IPv6 [RFC8986]
* TCP - Transmission Control Protocol [RFC9293] SSRC: Synchronization Source [RFC3550]
* TDM - Time Division Multiplexing SONET: Synchronous Optical Network
* TTS - Transmitter Training Signal TCP: Transmission Control Protocol [RFC9293]
* UAS - Unavailable Second TDM: Time Division Multiplexing
* VPWS - Virtual Private Wire Service [RFC3985] TTS: Transmitter Training Signal
* VC - Virtual Circuit UAS: Unavailable Seconds
* VT - Virtual Tributary VPWS: Virtual Private Wire Service [RFC3985]
The term Interworking Function (IWF) is used to describe the Note: The term Interworking Function (IWF) is used to describe the
functional block that encapsulates bit streams into PLE packets and functional block that encapsulates bit streams into PLE packets and
in the reverse direction decapsulates PLE packets and reconstructs in the reverse direction decapsulates PLE packets and reconstructs
bit streams. bit streams.
3.2. Reference Models 3.2. Reference Models
The reference model for PLE is illustrated in Figure 1 and is inline 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 with the reference model defined in Section 4.1 of [RFC3985]. PLE
does rely on PWE3 pre-processing, in particular the concept of a relies on PWE3 preprocessing, in particular the concept of a Native
Native Service Processing (NSP) function defined in Section 4.2.2 of Service Processing (NSP) function defined in Section 4.2.2 of
[RFC3985]. [RFC3985].
|<--- p2p L2VPN service -->| |<--- p2p L2VPN service -->|
| | | |
| |<-PSN tunnel->| | | |<-PSN tunnel->| |
v v v v v v v v
+---------+ +---------+ +---------+ +---------+
| PE1 |==============| PE2 | | PE1 |==============| PE2 |
+---+-----+ +-----+---+ +---+-----+ +-----+---+
+-----+ | N | | | | N | +-----+ +-----+ | N | | | | N | +-----+
skipping to change at page 8, line 4 skipping to change at line 312
+-----+ | N | | | | N | +-----+ +-----+ | N | | | | N | +-----+
| CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 | | CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 |
+-----+ ^ | P | | | | P | ^ +-----+ +-----+ ^ | P | | | | P | ^ +-----+
| +---+-----+ +-----+---+ | | +---+-----+ +-----+---+ |
CE1 physical ^ ^ CE2 physical CE1 physical ^ ^ CE2 physical
interface | | interface interface | | interface
|<--- emulated service --->| |<--- emulated service --->|
| | | |
attachment attachment attachment attachment
circuit circuit circuit circuit
Figure 1: PLE Reference Model Figure 1: PLE Reference Model
PLE embraces the minimum intervention principle outlined in PLE embraces the minimum intervention principle outlined in
Section 3.3.5 of [RFC3985] whereas the data is flowing through the Section 3.3.5 of [RFC3985] whereas the data is flowing through the
PLE encapsulation layer as received without modifications. PLE encapsulation layer as received without modifications.
For some service types the NSP function is responsible for performing For some service types, the NSP function is responsible for
operations on the native data received from the CE. Examples are performing operations on the native data received from the CE.
terminating Forward Error Correction (FEC), terminating the OTUk Examples are terminating Forward Error Correction (FEC), terminating
layer for OTN or dealing with multi-lane processing. After the NSP, the OTUk layer for OTN, or dealing with multi-lane processing. After
the IWF is generating the payload of the VPWS which is carried via a the NSP, the IWF is generating the payload of the VPWS, which is
PSN tunnel. carried via a PSN tunnel.
To allow the clock of the transported signal to be carried across the To allow the clock of the transported signal to be carried across the
PLE domain in a transparent way the relative network synchronization PLE domain in a transparent way, the relative network synchronization
reference model and deployment scenario outlined in Section 4.3.2 of reference model and deployment scenario outlined in Section 4.3.2 of
[RFC4197] are applicable and are shown in Figure 2. [RFC4197] are applicable and are shown in Figure 2.
J J
| G | G
| | | |
| +-----+ +-----+ v | +-----+ +-----+ v
+-----+ v |- - -|=================|- - -| +-----+ +-----+ v |- - -|=================|- - -| +-----+
| |<---------|.............................|<---------| | | |<---------|.............................|<---------| |
| CE1 | | PE1 | VPWS | PE2 | | CE2 | | CE1 | | PE1 | VPWS | PE2 | | CE2 |
skipping to change at page 8, line 47 skipping to change at line 356
|I| |I|
+-+ +-+
Figure 2: Relative Network Scenario Timing Figure 2: Relative Network Scenario Timing
The local oscillators C of PE1 and D of PE2 are locked to a common The local oscillators C of PE1 and D of PE2 are locked to a common
clock I. clock I.
The attachment circuit clock E is generated by PE2 via a differential The attachment circuit clock E is generated by PE2 via a differential
clock recovery method in reference to the common clock I. For this 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 to work, the difference between clock A and clock C (locked to I)
be explicitly transferred from PE1 to PE2 using the timestamp inside MUST be explicitly transferred from PE1 to PE2 using the timestamp
the RTP header. inside the RTP header.
For the reverse direction PE1 does generate the attachment circuit For the reverse direction, PE1 generates the attachment circuit clock
clock J and the clock difference between G and D (locked to I) J and the clock difference between G and D (locked to I) transferred
transferred from PE2 to PE1. from PE2 to PE1.
The method used to lock clocks C and D to the common clock I is out 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- of scope of this document; however, there are already several well-
established concepts for achieving clock synchronization, commonly established concepts for achieving clock synchronization (commonly
also referred to as frequency synchronization, available. also referred to as "frequency synchronization") available.
While using external timing inputs (aka BITS [ATIS-0900105.09.2013]) While using external timing inputs (aka BITS [ATIS-0900105.09.2013])
or synchronous Ethernet as defined in [G.8261] the characteristics or synchronous Ethernet (as defined in [G.8261]), the characteristics
and limits defined in [G.8262] have to be considered. and limits defined in [G.8262] have to be considered.
While relying on precision time protocol (PTP) as defined in While relying on precision time protocol (PTP) (as defined in
[G.8265.1], the network limits defined in [G.8261.1] have to be [G.8265.1]), the network limits defined in [G.8261.1] have to be
considered. considered.
4. Emulated Services 4. Emulated Services
This specification describes the emulation of services from a wide This specification describes the emulation of services from a wide
range of technologies, such as TDM, Ethernet, Fibre Channel, or OTN, 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 as bit streams or structured bit streams, as defined in Sections
and Section 3.3.4 of [RFC3985]. 3.3.3 and 3.3.4 of [RFC3985].
4.1. Generic PLE Service 4.1. Generic PLE Service
The generic PLE service is an example of the bit stream defined in The generic PLE service is an example of the bit stream defined in
Section 3.3.3 of [RFC3985]. Section 3.3.3 of [RFC3985].
Under the assumption that the CE-bound IWF is not responsible for any 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 service-specific operation, a bit stream of any rate can be carried
using the generic PLE payload. using the generic PLE payload.
There is no NSP function present for this service. There is no NSP function present for this service.
4.2. Ethernet services 4.2. Ethernet Services
Ethernet services are special cases of the structured bit stream Ethernet services are special cases of the structured bit stream
defined in Section 3.3.4 of [RFC3985]. defined in Section 3.3.4 of [RFC3985].
IEEE has defined several layers for Ethernet in [IEEE802.3]. The IEEE has defined several layers for Ethernet in [IEEE802.3].
Emulation is operating at the physical (PHY) layer, more precisely at Emulation is operating at the physical (PHY) layer, more precisely at
the Physical Coding Sublayer (PCS). the Physical Coding Sublayer (PCS).
Over time many different Ethernet interface types have been specified Over time, many different Ethernet interface types have been
in [IEEE802.3] with a varying set of characteristics such as optional specified in [IEEE802.3] with a varying set of characteristics, such
vs mandatory FEC and single-lane vs multi-lane transmission. as optional versus mandatory FEC and single-lane versus multi-lane
transmission.
Ethernet interface types with backplane physical media dependent Ethernet interface types with backplane physical media dependent
(PMD) variants and Ethernet interface types mandating auto- (PMD) variants and Ethernet interface types mandating auto-
negotiation (except 1000Base-X) are out of scope for this document. negotiation (except 1000Base-X) are out of scope for this document.
All Ethernet services are leveraging the basic PLE payload and All Ethernet services are leveraging the basic PLE payload and
interface specific mechanisms are confined to the respective service interface-specific mechanisms are confined to the respective service
specific NSP functions. specific NSP functions.
4.2.1. 1000BASE-X 4.2.1. 1000BASE-X
The PCS layer of 1000BASE-X defined in section 36 of [IEEE802.3] is The PCS layer of 1000BASE-X (defined in Section 36 of [IEEE802.3]) is
based on 8B/10B code. based on 8B/10B code.
The PSN-bound NSP function does not modify the received data and is The PSN-bound NSP function does not modify the received data and is
transparent to auto-negotiation but is responsible to detect transparent to auto-negotiation; however, it is responsible for
1000BASE-X specific attachment circuit faults such as LOS and sync detecting attachment circuit faults specific to 1000BASE-X such as
loss. LOS and sync loss.
When the CE-bound IWF is in PLOS state or when PLE packets are 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 received with the L bit set, the CE-bound NSP function MAY disable
disable its transmitter as no appropriate maintenance signal was its transmitter as no appropriate maintenance signal was defined for
defined for 1000BASE-X by IEEE. 1000BASE-X by the IEEE.
4.2.2. 10GBASE-R and 25GBASE-R 4.2.2. 10GBASE-R and 25GBASE-R
The PCS layers of 10GBASE-R defined in section 49 and 25GBASE-R The PCS layers of 10GBASE-R (defined in Section 49 and 25GBASE-R
defined in section 107 of [IEEE802.3] are based on a 64B/66B code. defined in Section 107 of [IEEE802.3]) are based on a 64B/66B code.
[IEEE802.3] sections 74 and 108 do define an optional FEC layer, if Sections 74 and 108 of [IEEE802.3] define an optional FEC layer; if
present the PSN-bound NSP function MUST terminate the FEC and the CE- present, the PSN-bound NSP function MUST terminate the FEC and the
bound NSP function MUST generate the FEC. CE-bound NSP function MUST generate the FEC.
The PSN-bound NSP function is also responsible to detect 10GBASE-R The PSN-bound NSP function is also responsible for detecting
and 25GBASE-R specific attachment circuit faults such as LOS and sync attachment circuit faults specific to 10GBASE-R and 25GBASE-R such as
loss. LOS and sync loss.
The PSN-bound IWF is mapping the scrambled 64B/66B code stream into The PSN-bound IWF maps the scrambled 64B/66B code stream into the
the basic PLE payload. basic PLE payload.
The CE-bound NSP function MUST perform The CE-bound NSP function MUST perform:
* PCS code sync (section 49.2.9 of [IEEE802.3]) * PCS code sync (Section 49.2.9 of [IEEE802.3])
* descrambling (section 49.2.10 of [IEEE802.3]) * descrambling (Section 49.2.10 of [IEEE802.3])
in order to properly:
in order to properly
* transform invalid 66B code blocks into proper error control * transform invalid 66B code blocks into proper error control
characters /E/ (section 49.2.4.11 of [IEEE802.3]) characters /E/ (Section 49.2.4.11 of [IEEE802.3])
* insert Local Fault (LF) ordered sets (section 46.3.4 of * insert Local Fault (LF) ordered sets (Section 46.3.4 of
[IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE
packets are received with the L-bit being set packets are received with the L bit set.
Note: Invalid 66B code blocks typically are a consequence of the CE- Note: Invalid 66B code blocks typically are a consequence of the CE-
bound IWF inserting replacement data in case of lost PLE packets, or 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 the far-end PSN-bound NSP function setting sync headers to 11 due to
to uncorrectable FEC errors. uncorrectable FEC errors.
Before sending the bit stream to the CE, the CE-bound NSP function Before sending the bit stream to the CE, the CE-bound NSP function
MUST also scramble the 64B/66B code stream (section 49.2.6 MUST also scramble the 64B/66B code stream (Section 49.2.6
[IEEE802.3]). [IEEE802.3]).
4.2.3. 40GBASE-R, 50GBASE-R and 100GBASE-R 4.2.3. 40GBASE-R, 50GBASE-R, and 100GBASE-R
The PCS layers of 40GBASE-R and 100GBASE-R defined in section 82 and The PCS layers of 40GBASE-R and 100GBASE-R (defined in Section 82 of
of 50GBASE-R defined in section 133 of [IEEE802.3] are based on a [IEEE802.3]) and of 50GBASE-R (defined in Section 133 of [IEEE802.3])
64B/66B code transmitted over multiple lanes. are based on a 64B/66B code transmitted over multiple lanes.
[IEEE802.3] sections 74 and 91 do define an optional FEC layer, if Sections 74 and 91 of [IEEE802.3] define an optional FEC layer; if
present the PSN-bound NSP function MUST terminate the FEC and the CE- present, the PSN-bound NSP function MUST terminate the FEC and the
bound NSP function MUST generate the FEC. CE-bound NSP function MUST generate the FEC.
To gain access to the scrambled 64B/66B code stream the PSN-bound NSP To gain access to the scrambled 64B/66B code stream, the PSN-bound
further MUST perform NSP further MUST perform:
* block synchronization (section 82.2.12 of [IEEE802.3]) * block synchronization (Section 82.2.12 of [IEEE802.3])
* PCS lane de-skew (section 82.2.13 of [IEEE802.3]) * PCS lane de-skew (Section 82.2.13 of [IEEE802.3])
* PCS lane reordering (section 82.2.14 of [IEEE802.3]) * PCS lane reordering (Section 82.2.14 of [IEEE802.3])
The PSN-bound NSP function is also responsible to detect 40GBASE-R, The PSN-bound NSP function is also responsible for detecting
50GBASE-R and 100GBASE-R specific attachment circuit faults such as attachment circuit faults specific to 40GBASE-R, 50GBASE-R, and
LOS and loss of alignment. 100GBASE-R such as LOS and loss of alignment.
The PSN-bound IWF is mapping the serialized and scrambled 64B/66B The PSN-bound IWF maps the serialized and scrambled 64B/66B code
code stream including the alignment markers into the basic PLE stream including the alignment markers into the basic PLE payload.
payload.
The CE-bound NSP function MUST perform The CE-bound NSP function MUST perform:
* PCS code sync (section 82.2.12 of [IEEE802.3]) * PCS code sync (Section 82.2.12 of [IEEE802.3])
* alignment marker removal (section 82.2.15 of [IEEE802.3]) * alignment-marker removal (Section 82.2.15 of [IEEE802.3])
* descrambling (section 49.2.10 of [IEEE802.3])
in order to properly * descrambling (Section 49.2.10 of [IEEE802.3])
in order to properly:
* transform invalid 66B code blocks into proper error control * transform invalid 66B code blocks into proper error control
characters /E/ (section 82.2.3.10 of [IEEE802.3]) characters /E/ (Section 82.2.3.10 of [IEEE802.3])
* insert Local Fault (LF) ordered sets (section 81.3.4 of * insert Local Fault (LF) ordered sets (Section 81.3.4 of
[IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE
packets are received with the L-bit being set packets are received with the L bit set
Note: Invalid 66B code blocks typically are a consequence of the CE- Note: Invalid 66B code blocks typically are a consequence of the CE-
bound IWF inserting replacement data in case of lost PLE packets, or 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 the far-end PSN-bound NSP function not setting sync headers to 11 due
to uncorrectable FEC errors. to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform also perform:
* scrambling of the 64B/66B code (section 49.2.6 of [IEEE802.3]) * scrambling of the 64B/66B code (Section 49.2.6 of [IEEE802.3])
* block distribution (section 82.2.6 of [IEEE802.3]) * block distribution (Section 82.2.6 of [IEEE802.3])
* alignment marker insertion (sections 82.2.7 and 133.2.2 of * alignment-marker insertion (Sections 82.2.7 and 133.2.2 of
[IEEE802.3]) [IEEE802.3])
4.2.4. 200GBASE-R and 400GBASE-R 4.2.4. 200GBASE-R and 400GBASE-R
The PCS layers of 200GBASE-R and 400GBASE-R defined in section 119 of The PCS layers of 200GBASE-R and 400GBASE-R (defined in Section 119
[IEEE802.3] are based on a 64B/66B code transcoded to a 256B/257B 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. 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 To gain access to the 64B/66B code stream, the PSN-bound NSP further
MUST perform MUST perform:
* alignment lock and de-skew (section 119.2.5.1 of [IEEE802.3]) * alignment lock and de-skew (Section 119.2.5.1 of [IEEE802.3])
* PCS Lane reordering and de-interleaving (section 119.2.5.2 of * PCS Lane reordering and de-interleaving (Section 119.2.5.2 of
[IEEE802.3]) [IEEE802.3])
* FEC decoding (section 119.2.5.3 of [IEEE802.3]) * FEC decoding (Section 119.2.5.3 of [IEEE802.3])
* post-FEC interleaving (section 119.2.5.4 of [IEEE802.3]) * post-FEC interleaving (Section 119.2.5.4 of [IEEE802.3])
* alignment marker removal (section 119.2.5.5 of [IEEE802.3]) * alignment-marker removal (Section 119.2.5.5 of [IEEE802.3])
* descrambling (section 119.2.5.6 of [IEEE802.3]) * descrambling (Section 119.2.5.6 of [IEEE802.3])
* reverse transcoding from 256B/257B to 64B/66B (section 119.2.5.7
* reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7
of [IEEE802.3]) of [IEEE802.3])
Further the PSN-bound NSP MUST perform rate compensation and Further, the PSN-bound NSP MUST perform rate compensation and
scrambling (section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF scrambling (Section 49.2.6 of [IEEE802.3]) before the PSN-bound IWF
is mapping the same into the basic PLE payload. maps the same into the basic PLE payload.
Rate compensation is applied so that the rate of the 66B encoded bit 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 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 200GBASE-R or 400GBASE-R at the PMA service interface. X number of
66 byte long rate compensation blocks are inserted every X*20479 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 number of 66B client blocks. For 200GBASE-R, the value of X is 16;
for 400GBASE-R the value of X is 32. Rate compensation blocks are for 400GBASE-R, the value of X is 32. Rate compensation blocks are
special 66B control characters of type 0x00 that can easily be special 66B control characters of type 0x00 that can easily be
searched for by the CE-bound IWF in order to remove them. searched for by the CE-bound IWF in order to remove them.
The PSN-bound NSP function is also responsible to detect 200GBASE-R The PSN-bound NSP function is also responsible for detecting
and 400GBASE-R specific attachment circuit faults such as LOS and attachment circuit faults specific to 200GBASE-R and 400GBASE-R such
loss of alignment. as LOS and loss of alignment.
The CE-bound NSP function MUST perform The CE-bound NSP function MUST perform:
* PCS code sync (section 49.2.13 of [IEEE802.3]) * PCS code sync (Section 49.2.13 of [IEEE802.3])
* descrambling (section 49.2.10 of [IEEE802.3]) * descrambling (Section 49.2.10 of [IEEE802.3])
* rate compensation block removal * rate compensation block removal
in order to properly in order to properly:
* transform invalid 66B code blocks into proper error control * transform invalid 66B code blocks into proper error control
characters /E/ (section 119.2.3.9 of [IEEE802.3]) characters /E/ (Section 119.2.3.9 of [IEEE802.3])
* insert Local Fault (LF) ordered sets (section 81.3.4 of * insert Local Fault (LF) ordered sets (Section 81.3.4 of
[IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE [IEEE802.3]) when the CE-bound IWF is in PLOS state or when PLE
packets are received with the L-bit being set packets are received with the L bit set
Note: Invalid 66B code blocks typically are a consequence of the CE- Note: Invalid 66B code blocks typically are a consequence of the CE-
bound IWF inserting replacement data in case of lost PLE packets, or 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 the far-end PSN-bound NSP function not setting sync headers to 11 due
to uncorrectable FEC errors. to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform also perform:
* transcoding from 64B/66B to 256B/257B (section 119.2.4.2 of * transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of
[IEEE802.3]) [IEEE802.3])
* scrambling (section 119.2.4.3 of [IEEE802.3]) * scrambling (Section 119.2.4.3 of [IEEE802.3])
* alignment marker insertion (section 119.2.4.4 of [IEEE802.3]) * alignment-marker insertion (Section 119.2.4.4 of [IEEE802.3])
* pre-FEC distribution (section 119.2.4.5 of [IEEE802.3]) * pre-FEC distribution (Section 119.2.4.5 of [IEEE802.3])
* FEC encoding (section 119.2.4.6 of [IEEE802.3]) * FEC encoding (Section 119.2.4.6 of [IEEE802.3])
* PCS Lane distribution (section 119.2.4.8 of [IEEE802.3]) * PCS Lane distribution (Section 119.2.4.8 of [IEEE802.3])
4.2.5. Energy Efficient Ethernet (EEE) 4.2.5. Energy Efficient Ethernet (EEE)
Section 78 of [IEEE802.3] does define the optional Low Power Idle Section 78 of [IEEE802.3] defines the optional Low Power Idle (LPI)
(LPI) capability for Ethernet. Two modes are defined capability for Ethernet. Two modes are defined:
* deep sleep * deep sleep
* fast wake * fast wake
Deep sleep mode is not compatible with PLE due to the CE ceasing Deep sleep mode is not compatible with PLE due to the CE ceasing
transmission. Hence there is no support for LPI for 10GBASE-R transmission. Hence, there is no support for LPI for 10GBASE-R
services across PLE. services across PLE.
When in fast wake mode the CE transmits /LI/ control code blocks In fast wake mode, the CE transmits /LI/ control code blocks instead
instead of /I/ control code blocks and therefore PLE is agnostic to of /I/ control code blocks and, therefore, PLE is agnostic to it.
it. For 25GBASE-R and higher services across PLE, LPI is supported For 25GBASE-R and higher services across PLE, LPI is supported as
as only fast wake mode is applicable. only fast wake mode is applicable.
4.3. SONET/SDH Services 4.3. SONET/SDH Services
SONET/SDH services are special cases of the structured bit stream SONET/SDH services are special cases of the structured bit stream
defined in Section 3.3.4 of [RFC3985]. defined in Section 3.3.4 of [RFC3985].
SDH interfaces are defined in [G.707] and SONET interfaces are SDH interfaces are defined in [G.707]; SONET interfaces are defined
defined in [GR253]. in [GR253].
The PSN-bound NSP function does not modify the received data but is The PSN-bound NSP function does not modify the received data but is
responsible to detect SONET/SDH interface specific attachment circuit responsible for detecting attachment circuit faults specific to
faults such as LOS, LOF and OOF. SONET/SDH such as LOS, LOF, and OOF.
Data received by the PSN-bound IWF is mapped into the basic PLE Data received by the PSN-bound IWF is mapped into the basic PLE
payload without any awareness of SONET/SDH frames. payload without any awareness of SONET/SDH frames.
When the CE-bound IWF is in PLOS state or when PLE packets are 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 received with the L bit set, the CE-bound NSP function is responsible
responsible for generating the for generating the:
* MS-AIS maintenance signal defined in section 6.2.4.1.1 of [G.707]
for SDH services
* AIS-L maintenance signal defined in section 6.2.1.2 of [GR253] for * MS-AIS maintenance signal (defined in Section 6.2.4.1.1 of
SONET services [G.707]) for SDH services
at client frame boundaries. * AIS-L maintenance signal (defined in Section 6.2.1.2 of [GR253])
for SONET services
at client-frame boundaries.
4.4. Fibre Channel Services 4.4. Fibre Channel Services
Fibre Channel services are special cases of the structured bit stream Fibre Channel services are special cases of the structured bit stream
defined in Section 3.3.4 of [RFC3985]. defined in Section 3.3.4 of [RFC3985].
The T11 technical committee of INCITS has defined several layers for The T11 technical committee of INCITS has defined several layers for
Fibre Channel. PLE operates at the FC-1 layer that leverages Fibre Channel. PLE operates at the FC-1 layer that leverages
mechanisms defined by [IEEE802.3]. mechanisms defined by [IEEE802.3].
Over time many different Fibre Channel interface types have been Over time, many different Fibre Channel interface types have been
specified with a varying set of characteristics such as optional vs specified with a varying set of characteristics such as optional
mandatory FEC and single-lane vs multi-lane transmission. versus mandatory FEC and single-lane versus multi-lane transmission.
Speed negotiation is not supported by PLE. Speed negotiation is not supported by PLE.
All Fibre Channel services are leveraging the basic PLE payload and All Fibre Channel services leverage the basic PLE payload, and
interface specific mechanisms are confined to the respective service interface-specific mechanisms are confined to the respective service-
specific NSP functions. specific NSP functions.
4.4.1. 1GFC, 2GFC, 4GFC and 8GFC 4.4.1. 1GFC, 2GFC, 4GFC, and 8GFC
[FC-PI-2] specifies 1GFC and 2GFC. [FC-PI-5] and [FC-PI-5am1] do [FC-PI-2] specifies 1GFC and 2GFC. [FC-PI-5] and [FC-PI-5am1] define
define 4GFC and 8GFC. 4GFC and 8GFC.
The PSN-bound NSP function is responsible to detect Fibre Channel The PSN-bound NSP function is responsible for detecting attachment
specific attachment circuit faults such as LOS and sync loss. circuit faults specific to the Fibre Channel such as LOS and sync
loss.
The PSN-bound IWF is mapping the received 8B/10B code stream as is The PSN-bound IWF maps the received 8B/10B code stream as is directly
directly into the basic PLE payload. into the basic PLE payload.
The CE-bound NSP function MUST perform transmission word sync in The CE-bound NSP function MUST perform transmission word sync in
order to properly order to properly:
* replace invalid transmission words with the special character * replace invalid transmission words with the special character
K30.7 K30.7
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is * 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 in PLOS state or when PLE packets are received with the L bit set
being set
Note: Invalid transmission words typically are a consequence of the Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets. 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 [FC-PI-5am1] defines the use of scrambling for 8GFC; in this case,
the CE-bound NSP MUST also perform descrambling before replacing the CE-bound NSP MUST also perform descrambling before replacing
invalid transmission words or inserting NOS ordered sets. And before invalid transmission words or inserting NOS ordered sets. Before
sending the bit stream to the, the CE-bound NSP function MUST sending the bit stream to the CE, the CE-bound NSP function MUST
scramble the 8B/10B code stream. scramble the 8B/10B code stream.
4.4.2. 16GFC 4.4.2. 16GFC
[FC-PI-5] and [FC-PI-5am1] specify 16GFC and define a optional FEC [FC-PI-5] and [FC-PI-5am1] specify 16GFC and define an optional FEC
layer. layer.
If FEC is present it must be indicated via transmitter training If FEC is present, it must be indicated via transmitter training
signal (TTS) during attachment circuit bring up. Further the PSN- signal (TTS) when the attachment circuit is brought up. Further, the
bound NSP function MUST terminate the FEC and the CE-bound NSP PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP
function must generate the FEC. function must generate the FEC.
The PSN-bound NSP function is responsible to detect Fibre Channel The PSN-bound NSP function is responsible for detecting attachment
specific attachment circuit faults such as LOS and sync loss. circuit faults specific to the Fibre Channel such as LOS and sync
loss.
The PSN-bound IWF is mapping the received scrambled 64B/66B code The PSN-bound IWF maps the received scrambled 64B/66B code stream as
stream as is into the basic PLE payload. is into the basic PLE payload.
The CE-bound NSP function MUST perform The CE-bound NSP function MUST perform:
* transmission word sync (section 49.2.13 of [IEEE802.3]) * transmission word sync (Section 49.2.13 of [IEEE802.3])
* descrambling (section 49.2.10 of [IEEE802.3]) * descrambling (Section 49.2.10 of [IEEE802.3])
in order to properly in order to properly:
* replace invalid transmission words with the error transmission * replace invalid transmission words with the error transmission
word 1Eh word 1Eh
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is * 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 in PLOS state or when PLE packets are received with the L bit set
being set
Note: Invalid transmission words typically are a consequence of the Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets, 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 or the far-end PSN-bound NSP function not setting sync headers to 11
due to uncorrectable FEC errors. due to uncorrectable FEC errors.
Before sending the bit stream to the CE, the CE-bound NSP function Before sending the bit stream to the CE, the CE-bound NSP function
MUST also scramble the 64B/66B code stream (section 49.2.6 of MUST also scramble the 64B/66B code stream (Section 49.2.6 of
[IEEE802.3]). [IEEE802.3]).
4.4.3. 32GFC and 4-lane 128GFC 4.4.3. 32GFC and 4-Lane 128GFC
[FC-PI-6] specifies 32GFC and [FC-PI-6P] specifies 4-lane 128GFC, [FC-PI-6] specifies 32GFC and [FC-PI-6P] specifies 4-lane 128GFC,
both with FEC layer and TTS support being mandatory. both with FEC layer and TTS support being mandatory.
To gain access to the 64B/66B code stream the PSN-bound NSP further To gain access to the 64B/66B code stream the PSN-bound NSP further
MUST perform MUST perform:
* descrambling (section of 49.2.10 of [IEEE802.3]) * descrambling (Section of 49.2.10 of [IEEE802.3])
* FEC decoding (section 91.5.3.3 of [IEEE802.3]) * FEC decoding (Section 91.5.3.3 of [IEEE802.3])
* reverse transcoding from 256B/257B to 64B/66B (section 119.2.5.7 * reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7
of [IEEE802.3]) of [IEEE802.3])
Further the PSN-bound NSP MUST perform scrambling (section 49.2.6 of Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of
[IEEE802.3]) before the PSN-bound IWF is mapping the same into the [IEEE802.3]) before the PSN-bound IWF maps the same into the basic
basic PLE payload. PLE payload.
The PSN-bound NSP function is also responsible to detect Fibre The PSN-bound NSP function is also responsible for detecting
Channel specific attachment circuit faults such as LOS and sync loss. attachment circuit faults specific to the Fibre Channel such as LOS
and sync loss.
The CE-bound NSP function MUST perform The CE-bound NSP function MUST perform:
* transmission word sync (section 119.2.6.3 of [IEEE802.3]) * transmission word sync (Section 119.2.6.3 of [IEEE802.3])
* descrambling (section 49.2.10 of [IEEE802.3]) * descrambling (Section 49.2.10 of [IEEE802.3])
in order to properly in order to properly:
* replace invalid transmission words with the error transmission * replace invalid transmission words with the error transmission
word 1Eh word 1Eh
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is * 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 in PLOS state or when PLE packets are received with the L bit set
being set
Note: Invalid transmission words typically are a consequence of the Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets, 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 or the far-end PSN-bound NSP function not setting sync headers to 11
due to uncorrectable FEC errors. due to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform also perform:
* transcoding from 64B/66B to 256B/257B (section 119.2.4.2 of * transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of
[IEEE802.3]) [IEEE802.3])
* FEC encoding (section 91.5.2.7 of [IEEE802.3]) * FEC encoding (Section 91.5.2.7 of [IEEE802.3])
* scrambling (section 49.2.6 of [IEEE802.3]) * scrambling (Section 49.2.6 of [IEEE802.3])
4.4.4. 64GFC 4.4.4. 64GFC
[FC-PI-7] specifies 64GFC with a mandatory FEC layer. [FC-PI-7] specifies 64GFC with a mandatory FEC layer.
To gain access to the 64B/66B code stream the PSN-bound NSP further To gain access to the 64B/66B code stream, the PSN-bound NSP further
MUST perform MUST perform:
* alignment lock (section 134.5.4 of [IEEE802.3] modified to single * alignment lock (Section 134.5.4 of [IEEE802.3] modified to single
FEC lane operation) FEC lane operation)
* FEC decoding (section 134.5.3.3 of [IEEE802.3]) * FEC decoding (Section 134.5.3.3 of [IEEE802.3])
* alignment marker removal (section 134.5.3.4 of [IEEE802.3]) * alignment-marker removal (Section 134.5.3.4 of [IEEE802.3])
* reverse transcoding from 256B/257B to 64B/66B (section 91.5.3.5 of * reverse transcoding from 256B/257B to 64B/66B (Section 91.5.3.5 of
[IEEE802.3]) [IEEE802.3])
Further the PSN-bound NSP MUST perform scrambling (section 49.2.6 of Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of
[IEEE802.3]) before the PSN-bound IWF is mapping the same into the [IEEE802.3]) before the PSN-bound IWF maps the same into the basic
basic PLE payload. PLE payload.
The PSN-bound NSP function is also responsible to detect Fibre The PSN-bound NSP function is also responsible for detecting
Channel specific attachment circuit faults such as LOS and sync loss. attachment circuit faults specific to the Fibre Channel such as LOS
and sync loss.
The CE-bound NSP function MUST perform The CE-bound NSP function MUST perform:
* transmission word sync (section 49.2.13 of [IEEE802.3]) * transmission word sync (Section 49.2.13 of [IEEE802.3])
* descrambling (section 49.2.10 of [IEEE802.3]) * descrambling (Section 49.2.10 of [IEEE802.3])
in order to properly in order to properly:
* replace invalid transmission words with the error transmission * replace invalid transmission words with the error transmission
word 1Eh word 1Eh
* insert Not Operational (NOS) ordered sets when the CE-bound IWF is * 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 in PLOS state or when PLE packets are received with the L bit set
being set
Note: Invalid transmission words typically are a consequence of the Note: Invalid transmission words typically are a consequence of the
CE-bound IWF inserting replacement data in case of lost PLE packets, 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 or the far-end PSN-bound NSP function not setting sync headers to 11
due to uncorrectable FEC errors. due to uncorrectable FEC errors.
When sending the bit stream to the CE, the CE-bound NSP function MUST When sending the bit stream to the CE, the CE-bound NSP function MUST
also perform also perform:
* transcoding from 64B/66B to 256B/257B (section 91.5.2.5 of * transcoding from 64B/66B to 256B/257B (Section 91.5.2.5 of
[IEEE802.3]) [IEEE802.3])
* alignment marker insertion (section 134.5.2.6 of [IEEE802.3]) * alignment-marker insertion (Section 134.5.2.6 of [IEEE802.3])
* FEC encoding (section 134.5.2.7 of [IEEE802.3]) * FEC encoding (Section 134.5.2.7 of [IEEE802.3])
4.5. OTN Services 4.5. OTN Services
OTN services are special cases of the structured bit stream defined OTN services are special cases of the structured bit stream defined
in Section 3.3.4 of [RFC3985]. in Section 3.3.4 of [RFC3985].
OTN interfaces are defined in [G.709]. OTN interfaces are defined in [G.709].
The PSN-bound NSP function MUST terminate the FEC and replace the The PSN-bound NSP function MUST terminate the FEC and replace the
OTUk overhead in row 1 columns 8-14 with all-zeros pattern which OTUk overhead in row 1, columns 8-14 with an all-zeros pattern; this
results in a extended ODUk frame as illustrated in Figure 3. The results in an extended ODUk frame as illustrated in Figure 3. The
frame alignment overhead (FA OH) in row 1 columns 1-7 is kept as it frame alignment overhead (FA OH) in row 1, columns 1-7 is kept as it
is. is.
column # column #
1 7 8 14 15 3824 1 7 8 14 15 3824
+--------+--------+------------------- .. --------------------+ +--------+--------+------------------- .. --------------------+
1| FA OH | All-0s | | 1| FA OH | All-0s | |
+--------+--------+ | +--------+--------+ |
r 2| | | r 2| | |
o | | | o | | |
w 3| ODUk overhead | | w 3| ODUk overhead | |
# | | | # | | |
4| | | 4| | |
+-----------------+------------------- .. --------------------+ +-----------------+------------------- .. --------------------+
Figure 3: Extended ODUk Frame Figure 3: Extended ODUk Frame
The PSN-bound NSP function is also responsible to detect OTUk The PSN-bound NSP function is also responsible for detecting
specific attachment circuit faults such as LOS, LOF, LOM and AIS. attachment circuit faults specific to OTUk such as LOS, LOF, LOM, and
AIS.
The PSN-bound IWF is mapping the extended ODUk frame into the byte The PSN-bound IWF maps the extended ODUk frame into the byte-aligned
aligned PLE payload. PLE payload.
The CE-bound NSP function will recover the ODUk by searching for the The CE-bound NSP function will recover the ODUk by searching for the
frame alignment overhead in the extended ODUk received from the CE- frame alignment overhead in the extended ODUk received from the CE-
bound IWF and generates the FEC. bound IWF and generating the FEC.
When the CE-bound IWF is in PLOS state or when PLE packets are 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 received with the L bit set, the CE-bound NSP function is responsible
responsible for generating the ODUk-AIS maintenance signal defined in for generating the ODUk-AIS maintenance signal defined in
section 16.5.1 of [G.709] at client frame boundaries. Section 16.5.1 of [G.709] at client-frame boundaries.
5. PLE Encapsulation Layer 5. PLE Encapsulation Layer
The basic packet format used by PLE is shown in the Figure 4. The basic packet format used by PLE is shown in Figure 4.
+-------------------------------+ -+ +-------------------------------+ -+
| PSN and VPWS Demux | \ | PSN and VPWS Demux | \
| (MPLS/SRv6) | > PSN and VPWS | (MPLS/SRv6) | > PSN and VPWS
| | / Demux Headers | | / Demux Headers
+-------------------------------+ -+ +-------------------------------+ -+
| PLE Control Word | \ | PLE Control Word | \
+-------------------------------+ > PLE Header +-------------------------------+ > PLE Header
| RTP Header | / | RTP Header | /
+-------------------------------+ --+ +-------------------------------+ --+
| Bit Stream | \ | Bit Stream | \
| Payload | > Payload | Payload | > Payload
| | / | | /
+-------------------------------+ --+ +-------------------------------+ --+
Figure 4: PLE Encapsulation Layer Figure 4: PLE Encapsulation Layer
5.1. PSN and VPWS Demultiplexing Headers 5.1. PSN and VPWS Demultiplexing Headers
This document does not imply any specific technology to be used for This document does not suggest any specific technology be used for
implementing the VPWS demultiplexing and PSN layers. implementing the VPWS demultiplexing and PSN layers.
The total size of a PLE packet for a specific PW MUST NOT exceed the 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. path MTU between the pair of PEs terminating this PW.
When a MPLS PSN layer is used, a VPWS label provides the When an MPLS PSN layer is used, a VPWS label provides the
demultiplexing mechanism as described in Section 5.4.2 of [RFC3985]. demultiplexing mechanism (as described in Section 5.4.2 of
The PSN tunnel can be a simple best path Label Switched Path (LSP) [RFC3985]). The PSN tunnel can be a simple best-path Label Switched
established using LDP [RFC5036] or Segment Routing (SR) [RFC8402] or Path (LSP) established using LDP (see [RFC5036]) or Segment Routing
a traffic engineered LSP established using RSVP-TE [RFC3209] or SR (SR) (see [RFC8402]); or it can be a traffic-engineered LSP
policies [RFC9256]. established using RSVP-TE (see [RFC3209]) or SR policies (see
[RFC9256]).
When a SRv6 PSN layer is used, a SRv6 service segment identifier When an SRv6 PSN layer is used, an SRv6 service Segment Identifier
(SID) as defined in [RFC8402] does provide the demultiplexing (SID) (as defined in [RFC8402]) provides the demultiplexing mechanism
mechanism and definitions of Section 6 of [RFC9252] do apply. Both and definitions of Section 6 of [RFC9252] apply. Both SRv6 service
SRv6 service SIDs with the full IPv6 address format defined in SIDs with the full IPv6 address format defined in [RFC8986] and
[RFC8986] and compressed SIDs (C-SIDs) with format defined in compressed SIDs (C-SIDs) with the format defined in [RFC9800] can be
[I-D.draft-ietf-spring-srv6-srh-compression] can be used. used.
5.1.1. New SRv6 Behaviors 5.1.1. New SRv6 Behaviors
Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are Two new encapsulation behaviors, H.Encaps.L1 and H.Encaps.L1.Red, are
defined in this document. The behavior procedures are applicable to defined in this document. The behavior procedures are applicable to
both SIDs and C-SIDs. both SIDs and C-SIDs.
The H.Encaps.L1 behavior encapsulates a frame received from an IWF in The H.Encaps.L1 behavior encapsulates a frame received from an IWF in
a IPv6 packet with an segment routing header (SRH). The received an IPv6 packet with a segment routing header (SRH). The received
frame becomes the payload of the new IPv6 packet. frame becomes the payload of the new IPv6 packet.
* The next header field of the SRH or the last extension header * The next header field of the SRH or the last extension header
present MUST be set to TBA1. present MUST be set to 147.
* The insertion of the SRH MAY be omitted per [RFC8986] when the * The insertion of the SRH MAY be omitted per [RFC8986] when the
SRv6 policy only contains one segment and there is no need to use SRv6 policy only contains one segment and there is no need to use
any flag, tag, or TLV. any flag, tag, or TLV.
The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1
behavior. behavior.
* H.Encaps.L1.Red reduces the length of the SRH by excluding the * H.Encaps.L1.Red reduces the length of the SRH by excluding the
first SID in the SRH. The first SID is only placed in the first SID in the SRH. The first SID is only placed in the
destination IPv6 address field. destination IPv6 address field.
* The insertion of the SRH MAY be omitted per [RFC8986] when the * The insertion of the SRH MAY be omitted per [RFC8986] when the
SRv6 policy only contains one segment and there is no need to use SRv6 policy only contains one segment and there is no need to use
any flag, tag, or TLV. any flag, tag, or TLV.
Three new "Endpoint with decapsulation and bit-stream cross-connect" Three new "Endpoint with decapsulation and bit-stream cross-connect"
behaviors called End.DX1, End.DX1 with NEXT-CSID and End.DX1 with behaviors called "End.DX1", "End.DX1 with NEXT-CSID", and "End.DX1
REPLACE-CSID are defined in this document. These new behaviors are with REPLACE-CSID" are defined in this document. These new behaviors
variants of End.DX2 defined in [RFC8986] and all have the following are variants of End.DX2 defined in [RFC8986], and they all have the
procedures in common. following procedures in common:
The End.DX1 SID MUST be the last segment in an SR Policy, and it is 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 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: to S and S is a local End.DX1 SID, N does the following:
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered) with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
skipping to change at page 22, line 4 skipping to change at line 983
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address S03. Send an ICMP Parameter Problem to the Source Address
with Code 0 (Erroneous header field encountered) with Code 0 (Erroneous header field encountered)
and Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
When processing the next (Upper-Layer) header of a packet matching a When processing the next (Upper-Layer) header of a packet matching a
FIB entry locally instantiated as an End.DX1 SID, N does the FIB entry locally instantiated as an End.DX1 SID, N does the
following: following:
S01. If (Upper-Layer header type == TBA1 (bit-stream) ) { S01. If (Upper-Layer header type == 147 (bit-stream) ) {
S02. Remove the outer IPv6 header with all its extension headers S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the remaining frame to the IWF I S03. Forward the remaining frame to the IWF I
S04. } Else { S04. } Else {
S05. Process as per {{Section 4.1.1 of RFC8986}} S05. Process as per {{Section 4.1.1 of RFC 8986}}
S06. } S06. }
5.2. PLE Header 5.2. PLE Header
The PLE header MUST contain the PLE control word (4 bytes) and MUST The PLE header MUST contain the PLE control word (4 bytes) and MUST
include a fixed size RTP header [RFC3550]. The RTP header MUST include a fixed-size RTP header [RFC3550]. The RTP header MUST
immediately follow the PLE control word. immediately follow the PLE control word.
5.2.1. PLE Control Word 5.2.1. PLE Control Word
The format of the PLE control word is in line with the guidance in The format of the PLE control word is in line with the guidance in
[RFC4385] and is shown in Figure 5. [RFC4385] and is shown in Figure 5.
0 1 2 3 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 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 | |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PLE Control Word Figure 5: PLE Control Word
The bits 0..3 of the first nibble are set to 0 to differentiate a 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 control word or Associated Channel Header (ACH) from an IP packet or
Ethernet frame. The first nibble MUST be set to 0000b to indicate 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 that this header is a control word as defined in Section 3 of
[RFC4385]. [RFC4385].
The other fields in the control word are used as defined below: The other fields in the control word are used as defined below:
* L L
Set by the PE to indicate that data carried in the payload is Set by the PE to indicate that data carried in the payload is
invalid due to an attachment circuit fault. The downstream PE invalid due to an attachment circuit fault. The downstream PE
MUST send appropriate replacement data. The NSP MAY inject an MUST send appropriate replacement data. The NSP MAY inject an
appropriate native fault propagation signal. appropriate native fault propagation signal.
* R R
Set by the downstream PE to indicate that the IWF experiences Set by the downstream PE to indicate that the IWF experiences
packet loss from the PSN or a server layer backward fault packet loss from the PSN or a server layer backward fault
indication is present in the NSP. The R bit MUST be cleared by 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. the PE once the packet loss state or fault indication has cleared.
* RSV RSV
These bits are reserved for future use. This field MUST be set to These bits are reserved for future use. This field MUST be set to
zero by the sender and ignored by the receiver. zero by the sender and ignored by the receiver.
* FRG FRG
These bits MUST be set to zero by the sender and ignored by the These bits MUST be set to zero by the sender and ignored by the
receiver as PLE does not use payload fragmentation. receiver as PLE does not use payload fragmentation.
* LEN LEN
In accordance with Section 3 of [RFC4385], the length field MUST
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 always be set to zero as there is no padding added to the PLE
packet. To detect malformed packets the default, preconfigured or packet. To detect malformed packets the default, preconfigured or
signaled payload size MUST be assumed. signaled payload size MUST be assumed.
* Sequence number Sequence number
The sequence number field is used to provide a common PW The sequence number field is used to provide a common PW
sequencing function as well as detection of lost packets. It MUST sequencing function as well as detection of lost packets. It MUST
be generated in accordance with the rules defined in Section 5.1 be generated in accordance with the rules defined in Section 5.1
of [RFC3550] and MUST be incremented with every PLE packet being of [RFC3550] and MUST be incremented with every PLE packet being
sent. sent.
5.2.2. RTP Header 5.2.2. RTP Header
The RTP header MUST be included to explicitly convey timing The RTP header MUST be included to explicitly convey timing
information. information.
The RTP header as defined in [RFC3550] is reused to align with other The RTP header (as defined in [RFC3550]) is reused to align with
bit-stream emulation pseudowires defined by [RFC4553], [RFC5086] and other bit-stream emulation pseudowires defined by [RFC4553],
[RFC4842] and to allow PLE implementations to reuse pre-existing [RFC5086], and [RFC4842] and to allow PLE implementations to reuse
work. preexisting work.
There is no intention to support full RTP topologies and protocol There is no intention to support full RTP topologies and protocol
mechanisms, such as header extensions, contributing source (CSRC) mechanisms, such as header extensions, contributing source (CSRC)
list, padding, RTP Control Protocol (RTCP), RTP header compression, list, padding, RTP Control Protocol (RTCP), RTP header compression,
Secure Realtime Transport Protocol (SRTP), etc., are not applicable Secure Real-time Transport Protocol (SRTP), etc., as these are not
to PLE VPWS. applicable to PLE VPWS.
The format of the RTP header is as shown in Figure 6. The format of the RTP header is as shown in Figure 6.
0 1 2 3 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 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 | |V=2|P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | | Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Synchronization Source (SSRC) Identifier | | Synchronization Source (SSRC) Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RTP Header Figure 6: RTP Header
* V: Version V:
Version
The version field MUST be set to 2. The version field MUST be set to 2.
* P: Padding P:
Padding
The padding flag MUST be set to zero by the sender and ignored by The padding flag MUST be set to zero by the sender and ignored by
the receiver. the receiver.
* X: Header extension X:
Header extension
The X bit MUST be set to zero by sender and ignored by receiver. The X bit MUST be set to zero by sender and ignored by receiver.
* CC: CSRC count CC:
CSRC count
The CC field MUST be set to zero by the sender and ignored by the The CC field MUST be set to zero by the sender and ignored by the
receiver. receiver.
* M: Marker M:
Marker
The M bit MUST be set to zero by the sender and ignored by the The M bit MUST be set to zero by the sender and ignored by the
receiver. receiver.
* PT: Payload type PT:
Payload type
A PT value MUST be allocated from the range of dynamic values A PT value MUST be allocated from the range of dynamic values
defined in Section 6 of [RFC3551] for each direction of the VPWS. defined in Section 6 of [RFC3551] for each direction of the VPWS.
The same PT value MAY be reused both for direction and between The same PT value MAY be reused both for direction and between
different PLE VPWS. different PLE VPWS.
The PT field MAY be used for detection of misconnections. The PT field MAY be used for detection of misconnections.
* Sequence number Sequence number
When using a 16 bit sequence number space, the sequence number in When using a 16-bit sequence number space, the sequence number in
the RTP header MUST be equal to the sequence number in the PLE the RTP header MUST be equal to the sequence number in the PLE
control word. When using a sequence number space of 32 bit, the control word. When using a sequence number space of 32 bits, the
initial value of the RTP sequence number MUST be 0 and incremented initial value of the RTP sequence number MUST be 0 and incremented
whenever the PLE control word sequence number cycles through from whenever the PLE control word sequence number cycles through from
0xFFFF to 0x0000. 0xFFFF to 0x0000.
* Timestamp Timestamp
Timestamp values are used in accordance with the rules established Timestamp values are used in accordance with the rules established
in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the in [RFC3550]. For bit-streams up to 200 Gbps, the frequency of
clock used for generating timestamps MUST be 125 MHz based on a the clock used for generating timestamps MUST be 125 MHz based on
the common clock I. For bit-streams above 200 Gbps the frequency a the common clock I. For bit-streams above 200 Gbps, the
MUST be 250 MHz. frequency MUST be 250 MHz.
* SSRC: Synchronization source SSRC:
Synchronization source
The SSRC field MAY be used for detection of misconnections. The SSRC field MAY be used for detection of misconnections.
6. PLE Payload Layer 6. PLE Payload Layer
A bit-stream is mapped into a PLE packet with a fixed payload size 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 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 directions of the VPWS, and MUST remain unchanged for the lifetime of
the VPWS. the VPWS.
All PLE implementations MUST be capable of supporting the default All PLE implementations MUST be capable of supporting the default
payload size of 1024 bytes. The payload size SHOULD be configurable payload size of 1024 bytes. The payload size SHOULD be configurable
to be able to address specific packetization delay and overhead to be able to address specific packetization delay and overhead
expectations. The smallest supported payload size is 64 bytes. expectations. The smallest supported payload size is 64 bytes.
6.1. Basic Payload 6.1. Basic Payload
The PLE payload is filled with incoming bits of the bit-stream The PLE payload is filled with incoming bits of the bit-stream
starting from the most significant to the least significant bit starting from the most significant to the least significant bit
without considering any structure of the bit-stream. without considering any structure of the bit-stream.
6.2. Byte aligned Payload 6.2. Byte-Aligned Payload
The PLE payload is filled in a byte aligned manner, where the order The PLE payload is filled in a byte-aligned manner, where the order
of the payload bytes corresponds to their order on the attachment of the payload bytes corresponds to their order on the attachment
circuit. Consecutive bits coming from the attachment circuit fill circuit. Consecutive bits coming from the attachment circuit fill
each payload byte starting from most significant bit to least each payload byte starting from most significant bit to least
significant. The PLE payload size MUST be an integer number of significant. The PLE payload size MUST be an integer number of
bytes. bytes.
7. PLE Operation 7. PLE Operation
7.1. Common Considerations 7.1. Common Considerations
A PLE VPWS can be established using manual configuration or A PLE VPWS can be established using manual configuration or
leveraging mechanisms of a signaling protocol. leveraging mechanisms of a signaling protocol.
Furthermore emulation of bit-stream signals using PLE is only Furthermore, emulation of bit-stream signals using PLE is only
possible when the two attachment circuits of the VPWS are of the same 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 service type (OC192, 10GBASE-R, ODU2, etc.) and are using the same
payload type and payload size. This can be ensured via manual PLE payload type and payload size. This can be ensured via manual
configuration or via the mechanisms of a signaling protocol. configuration or via the mechanisms of a signaling protocol.
PLE related control protocol extensions to LDP [RFC8077] or EVPN-VPWS PLE-related control protocol extensions to LDP [RFC8077] or EVPN-VPWS
[RFC8214] are out of scope for this document. [RFC8214] are out of scope for this document.
Extensions for EVPN-VPWS are proposed in Extensions for EVPN-VPWS are proposed in [EVPN-VPWS] and for LDP in
[I-D.draft-schmutzer-bess-bitstream-vpws-signalling] and for LDP in [LDP-PLE].
[I-D.draft-schmutzer-pals-ple-signaling].
7.2. PLE IWF Operation 7.2. PLE IWF Operation
7.2.1. PSN-bound Encapsulation Behavior 7.2.1. PSN-Bound Encapsulation Behavior
After the VPWS is set up, the PSN-bound IWF does perform the After the VPWS is set up, the PSN-bound IWF performs the following
following steps: steps:
* Packetize the data received from the CE is into PLE payloads, all * Packetize the data received from the CE into PLE payloads, all of
of the same configured size the same configured size
* Add PLE control word and RTP header with sequence numbers, flags * Add PLE control word and RTP header with sequence numbers, flags,
and timestamps properly set and timestamps properly set
* Add the VPWS demultiplexer and PSN headers * Add the VPWS demultiplexer and PSN headers
* Transmit the resulting packets over the PSN * Transmit the resulting packets over the PSN
* Set L bit in the PLE control word whenever attachment circuit * Set the L bit in the PLE control word whenever the attachment
detects a fault circuit detects a fault
* Set R bit in the PLE control word whenever the local CE-bound IWF * Set the R bit in the PLE control word whenever the local CE-bound
is in packet loss state IWF is in packet loss state
7.2.2. CE-bound Decapsulation Behavior 7.2.2. CE-Bound Decapsulation Behavior
The CE-bound IWF is responsible for removing the PSN and VPWS The CE-bound IWF is responsible for removing the PSN and VPWS
demultiplexing headers, PLE control word and RTP header from the demultiplexing headers, PLE control word, and RTP header from the
received packet stream and sending the bit-stream out via the local received packet stream and sending the bit-stream out via the local
attachment circuit. attachment circuit.
A de-jitter buffer MUST be implemented where the PLE packets are A de-jitter buffer MUST be implemented where the PLE packets are
stored upon arrival. The size of this buffer SHOULD be locally stored upon arrival. The size of this buffer SHOULD be locally
configurable to allow accommodation of specific PSN packet delay configurable to allow accommodation of specific PSN packet delay
variation (PDV) expected. variation (PDV) expected.
The CE-bound IWF SHOULD use the sequence number in the control word The CE-bound IWF SHOULD use the sequence number in the control word
to detect lost and misordered packets. It MAY use the sequence 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 number in the RTP header for the same purpose. The CE-bound IWF MAY
support re-ordering of packets received out of order. If the CE- support reordering of packets received out of order. If the CE-bound
bound IWF does not support re-ordering it MUST drop the misordered IWF does not support reordering, it MUST drop the misordered packets.
packets.
The payload of a lost or dropped packet MUST be replaced with The payload of a lost or dropped packet MUST be replaced with an
equivalent amount of replacement data. The contents of the equivalent amount of replacement data. The contents of the
replacement data MAY be locally configurable. By default, all PLE replacement data MAY be locally configurable. By default, all PLE
implementations MUST support generation of "0xAA" as replacement implementations MUST support generation of "0xAA" as replacement
data. The alternating sequence of 0s and 1s of the "0xAA" pattern data. The alternating sequence of 0s and 1s of the "0xAA" pattern
does ensure clock synchronization is maintained and for 64B/66B code ensures clock synchronization is maintained and, for 64B/66B code-
based services no invalid sync headers are generated. While sending based services, ensures no invalid sync headers are generated. While
out the replacement data, the IWF will apply a holdover mechanism to sending out the replacement data, the IWF will apply a holdover
maintain the clock. mechanism to maintain the clock.
Whenever the VPWS is not operationally up, the CE-bound NSP function Whenever the VPWS is not operationally up, the CE-bound NSP function
MUST inject the appropriate native downstream fault indication MUST inject the appropriate native downstream fault-indication
signal. signal.
Whenever a VPWS comes up, the CE-bound IWF enters the intermediate Whenever a VPWS comes up, the CE-bound IWF will enter the
state, will start receiving PLE packets and will store them in the intermediate state, will start receiving PLE packets, and will store
jitter buffer. The CE-bound NSP function will continue to inject the them in the jitter buffer. The CE-bound NSP function will continue
appropriate native downstream fault indication signal until a pre- to inject the appropriate native downstream fault-indication signal
configured number of payload s stored in the jitter buffer. until a preconfigured number of payload s stored in the jitter
buffer.
After the pre-configured amount of payload is present in the jitter After the preconfigured amount of payload is present in the jitter
buffer the CE-bound IWF transitions to the normal operation state and buffer, the CE-bound IWF transitions to the normal operation state,
the content of the jitter buffer is streamed out to the CE in 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 accordance with the required clock. In this state, the CE-bound IWF
MUST perform egress clock recovery. MUST perform egress clock recovery.
Considerations for choosing the pre-configured amount of payload Considerations for choosing the preconfigured amount of payload
required to be present for transitioning into the normal state: * required to be present for transitioning into the normal state:
Typically set to 50% of the de-jitter buffer size to equally allow
compensating for increasing and decreasing delay * Choosing a * Typically set to 50% of the de-jitter buffer size to equally allow
compromise between the maximum amount of tolerable PDV and delay compensating for increasing and decreasing delay
introduced to the emulated service
* A compromise between the maximum amount of tolerable PDV and delay
introduced to the emulated service
The recovered clock MUST comply with the jitter and wander The recovered clock MUST comply with the jitter and wander
requirements applicable to the type of attachment circuit, specified requirements applicable to the type of attachment circuit, specified
in: in:
* [G.825], [G.783] and [G.823] for SDH * [G.825], [G.783], and [G.823] for SDH
* [GR253] and [GR499] for SONET * [GR253] and [GR499] for SONET
* [G.8261] for synchronous Ethernet * [G.8261] for synchronous Ethernet
* [G.8251] for OTN * [G.8251] for OTN
Whenever the L bit is set in the PLE control word of a received PLE 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 packet, the CE-bound NSP function SHOULD inject the appropriate
downstream fault indication signal instead of streaming out the native downstream fault-indication signal instead of streaming out
payload. the payload.
If the CE-bound IWF detects loss of consecutive packets for a pre- If the CE-bound IWF detects loss of consecutive packets for a
configured amount of time (default is 1 millisecond), it enters preconfigured amount of time (default is 1 millisecond), it enters
packet loss (PLOS) state and a corresponding defect is declared. packet loss (PLOS) state and a corresponding defect is declared.
If the CE-bound IWF detects a packet loss ratio (PLR) above a If the CE-bound IWF detects a packet loss ratio (PLR) above a
configurable signal-degrade (SD) threshold for a configurable amount configurable signal-degrade (SD) threshold for a configurable amount
of consecutive 1-second intervals, it enters the degradation (DEG) of consecutive 1-second intervals, it enters the degradation (DEG)
state and a corresponding defect is declared. The SD-PLR threshold state and a corresponding defect is declared. The SD-PLR threshold
can be defined as percentage with the default being 15% or absolute can be defined as a percentage with the default being 15% or absolute
packet count for finer granularity for higher rate interfaces. packet count for finer granularity for higher rate interfaces.
Possible values for consecutive intervals are 2..10 with the default Possible values for consecutive intervals are 2..10 with the default
7. 7.
While the PLOS defect is declared the CE-bound NSP function MUST While the PLOS defect is declared, the CE-bound NSP function MUST
inject the appropriate native downstream fault indication signal. If inject the appropriate native downstream fault-indication signal. If
the emulated service does not have a appropriate maintenance signal the emulated service does not have an appropriate maintenance signal
defined, the CE-bound NSP function MAY disable its transmitter defined, the CE-bound NSP function MAY disable its transmitter
instead. Also the PSN-bound IWF SHOULD set the R bit in the PLE instead. Also, the PSN-bound IWF SHOULD set the R bit in the PLE
control word of every packet transmitted. control word of every packet transmitted.
The CE-bound IWF does change from the PLOS to normal state after the The CE-bound IWF changes from the PLOS to normal state after the
pre-configured amount of payload has been received similarly to the preconfigured amount of payload has been received similar to the
transition from intermediate to normal state. transition from intermediate to normal state.
Whenever the R bit is set in the PLE control word of a received PLE Whenever the R bit is set in the PLE control word of a received PLE
packet the PLE performance monitoring statistics SHOULD get updated. packet, the PLE performance monitoring statistics SHOULD get updated.
7.3. PLE Performance Monitoring 7.3. PLE Performance Monitoring
Attachment circuit performance monitoring SHOULD be provided by the Attachment circuit performance monitoring SHOULD be provided by the
NSP. The performance monitors are service specific, documented in NSP. The performance monitors are service specific, documented in
related specifications and beyond the scope of this document. related specifications, and beyond the scope of this document.
The PLE IWF SHOULD provide functions to monitor the network The PLE IWF SHOULD provide functions to monitor the network
performance to be inline with expectations of transport network performance to be inline with expectations of transport network
operators. operators.
The near-end performance monitors defined for PLE are as follows: The near-end performance monitors defined for PLE are as follows:
* ES-PLE : PLE Errored Seconds * ES-PLE : PLE Errored Seconds
* SES-PLE : PLE Severely Errored Seconds * SES-PLE : PLE Severely Errored Seconds
* UAS-PLE : PLE Unavailable Seconds * UAS-PLE : PLE Unavailable Seconds
Each second with at least one packet lost or a PLOS/DEG defect SHALL 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 be counted as an ES-PLE. Each second with a PLR greater than 15% or
PLOS/DEG defect SHALL be counted as SES-PLE. a PLOS/DEG defect SHALL be counted as an SES-PLE.
UAS-PLE SHALL be counted after a configurable number of consecutive UAS-PLE SHALL be counted after a configurable number of consecutive
SES-PLE have been observed, and no longer counted after a SES-PLEs have been observed, and no longer counted after a
configurable number of consecutive seconds without SES-PLE have been configurable number of consecutive seconds without an SES-PLE have
observed. Default value for each is 10 seconds. been observed. The default value for each is 10 seconds.
Once unavailability is detected, ES and SES counts SHALL be inhibited Once unavailability is detected, ES and SES counts SHALL be inhibited
up to the point where the unavailability was started. Once up to the point where the unavailability was started. Once
unavailability is removed, ES and SES that occurred along the unavailability is removed, ES and SES that occurred along the
clearing period SHALL be added to the ES and SES counts. clearing period SHALL be added to the ES and SES counts.
A PLE far-end performance monitor is providing insight into the CE- A PLE far-end performance monitor provides insight into the CE-bound
bound IWF at the far end of the PSN. The statistics are based on the IWF at the far end of the PSN. The statistics are based on the PLE-
PLE-RDI indication carried in the PLE control word via the R bit. RDI indication carried in the PLE control word via the R bit.
The PLE VPWS performance monitors are derived from the definitions in The PLE VPWS performance monitors are derived from the definitions in
accordance with [G.826] accordance with [G.826].
Performance monitoring data MUST be provided by the management Performance monitoring data MUST be provided by the management
interface and SHOULD be provided by a YANG model. The YANG model interface and SHOULD be provided by a YANG data model. The YANG data
specification is out of scope for this document. model specification is out of scope for this document.
7.4. PLE Fault Management 7.4. PLE Fault Management
Attachment circuit faults applicable to PLE are detected by the NSP, Attachment circuit faults applicable to PLE are detected by the NSP,
are service specific and are documented in relevant section of are service specific, and are documented in Section 4.
Section 4.
The two PLE faults, PLOS and DEG are detected by the IWF. The two PLE faults, PLOS and DEG, are detected by the IWF.
Faults MUST be time stamped as they are declared and cleared and Faults MUST be timestamped as they are declared and cleared; fault-
fault related information MUST be provided by the management related information MUST be provided by the management interface and
interface and SHOULD be provided by a YANG model. The YANG model SHOULD be provided by a YANG data model. The YANG data model
specification is out of scope for this document. specification is out of scope for this document.
8. QoS and Congestion Control 8. QoS and Congestion Control
The PSN carrying PLE VPWS may be subject to congestion. Congestion The PSN carrying PLE VPWS may be subject to congestion. Congestion
considerations for PWs are described in Section 6.5 of [RFC3985]. considerations for PWs are described in Section 6.5 of [RFC3985].
PLE VPWS represent inelastic constant bit-rate (CBR) flows that PLE VPWS represent inelastic constant bit-rate (CBR) flows that
cannot respond to congestion in a TCP-friendly manner as described in cannot respond to congestion in a TCP-friendly manner (as described
[RFC2914] and are sensitive to jitter, packet loss and packets in [RFC2914]) and are sensitive to jitter, packet loss, and packets
received out of order. received out of order.
The PSN providing connectivity between PE devices of a PLE VPWS has The PSN providing connectivity between PE devices of a PLE VPWS has
to ensure low jitter and low loss. The exact mechanisms used are to ensure low jitter and low loss. The exact mechanisms used are
beyond the scope of this document and may evolve over time. Possible beyond the scope of this document and may evolve over time. Possible
options, but not exhaustively, are a Diffserv-enabled [RFC2475] PSN options, but not exhaustively, are as follows
with a per domain behavior [RFC3086] supporting Expedited Forwarding
[RFC3246]. Traffic-engineered paths through the PSN with bandwidth * a Diffserv-enabled [RFC2475] PSN with a per-domain behavior (see
reservation and admission control applied. Or capacity over- [RFC3086]) supporting Expedited Forwarding (see [RFC3246]),
provisioning.
* traffic-engineered paths through the PSN with bandwidth
reservation and admission control applied, or
* capacity over-provisioning.
9. Security Considerations 9. Security Considerations
As PLE is leveraging VPWS as transport mechanism, the security As PLE is leveraging VPWS as transport mechanism, the security
considerations described [RFC3985] are applicable. considerations described in [RFC3985] are applicable.
PLE does not enhance or detract from the security performance of the PLE does not enhance or detract from the security performance of the
underlying PSN. It relies upon the PSN mechanisms for encryption, underlying PSN. It relies upon the PSN mechanisms for encryption,
integrity, and authentication whenever required. integrity, and authentication whenever required.
The PSN (MPLS or SRv6) is assumed to be trusted and secure. The PSN (MPLS or SRv6) is assumed to be trusted and secure.
Attackers who manage to send spoofed packets into the PSN could Attackers who manage to send spoofed packets into the PSN could
easily disrupt the PLE service. This MUST be prevented by following easily disrupt the PLE service. This MUST be prevented by following
best practices for the isolation of the PSN. These protections are best practices for the isolation of the PSN. These protections are
described in the considerations in Section 3.4 of [RFC4381], described in Section 3.4 of [RFC4381], Section 4.2 of [RFC5920],
Section 4.2 of [RFC5920] in Section 8 of [RFC8402] and Section 9.3 of Section 8 of [RFC8402], and Section 9.3 of [RFC9252].
[RFC9252].
PLE PWs share susceptibility to a number of pseudowire-layer attacks PLE PWs share susceptibility to a number of pseudowire-layer attacks
and will use whatever mechanisms for confidentiality, integrity, and and will use whatever mechanisms for confidentiality, integrity, and
authentication that are developed for general PWs. These methods are authentication that are developed for general PWs. These methods are
beyond the scope of this document. beyond the scope of this document.
Random initialization of sequence numbers, in both the control word Random initialization of sequence numbers, in both the control word
and the RTP header, makes known-plaintext attacks more difficult. and the RTP header, makes known-plaintext attacks more difficult.
Misconnection detection using the SSRC and/or PT field of the RTP Misconnection detection using the SSRC and/or PT field of the RTP
header can increase the resilience to misconfiguration and some types header can increase the resilience to misconfiguration and some types
of denial-of-service (DoS) attacks. Randomly chosen expected values of denial-of-service (DoS) attacks. Randomly chosen expected values
do decrease the chance of a spoofing attack being successful. decrease the chance of a spoofing attack being successful.
A data plane attack may force PLE packets to be dropped, re-ordered A data plane attack may force PLE packets to be dropped, reordered,
or delayed beyond the limit of the CE-bound IWF's dejitter buffer or delayed beyond the limit of the CE-bound IWF's dejitter buffer
leading to either degradation or service disruption. Considerations leading to either degradation or service disruption. Considerations
outlined in [RFC9055] are a good reference. outlined in [RFC9055] are a good reference.
Clock synchronization leveraging PTP is sensitive to Packet Delay Clock synchronization leveraging PTP is sensitive to Packet Delay
Variation (PDV) and vulnerable to various threads and attack vectors. Variation (PDV) and vulnerable to various threads and attack vectors.
Considerations outlined in [RFC7384] should be taken into account. Considerations outlined in [RFC7384] should be taken into account.
10. IANA Considerations 10. IANA Considerations
10.1. Bit-stream Next Header Type 10.1. Bit-Stream Next Header Type
This document introduces a new value to be used in the next header 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 field of an IPv6 header or any extension header indicating that the
payload is a emulated bit-stream. IANA is requested to assign the payload is an emulated bit-stream. IANA has assigned the following
following from the "Assigned Internet Protocol Numbers" registry from the "Assigned Internet Protocol Numbers" registry [IANA-Proto].
[IANA-Proto].
+=========+=========+============+================+===========+ +=========+=========+============+================+===========+
| Decimal | Keyword | Protocol | IPv6 Extension | Reference | | Decimal | Keyword | Protocol | IPv6 Extension | Reference |
| | | | Header | | | | | | Header | |
+=========+=========+============+================+===========+ +=========+=========+============+================+===========+
| TBA1 | BIT-EMU | Bit-stream | Y | this | | 147 | BIT-EMU | Bit-stream | Y | This |
| | | Emulation | | document | | | | Emulation | | document |
+---------+---------+------------+----------------+-----------+ +---------+---------+------------+----------------+-----------+
Table 1 Table 1
10.2. SRv6 Endpoint Behaviors 10.2. SRv6 Endpoint Behaviors
This document introduces three new SRv6 Endpoint behaviors. IANA is This document introduces three new SRv6 Endpoint behaviors. IANA has
requested to assign identifier values in the "SRv6 Endpoint assigned identifier values in the "SRv6 Endpoint Behaviors" registry
Behaviors" sub-registry under "Segment Routing" registry under the "Segment Routing" registry group [IANA-SRv6-End].
[IANA-SRv6-End].
+=======+========+===========================+===============+ +=======+========+===========================+===============+
| Value | Hex | Endpoint Behavior | Reference | | Value | Hex | Endpoint Behavior | Reference |
+=======+========+===========================+===============+ +=======+========+===========================+===============+
| 158 | 0x009E | End.DX1 | this document | | 158 | 0x009E | End.DX1 | This document |
+-------+--------+---------------------------+---------------+ +-------+--------+---------------------------+---------------+
| 159 | 0x009F | End.DX1 with NEXT-CSID | this document | | 159 | 0x009F | End.DX1 with NEXT-CSID | This document |
+-------+--------+---------------------------+---------------+ +-------+--------+---------------------------+---------------+
| 160 | 0x00A0 | End.DX1 with REPLACE-CSID | this document | | 160 | 0x00A0 | End.DX1 with REPLACE-CSID | This document |
+-------+--------+---------------------------+---------------+ +-------+--------+---------------------------+---------------+
Table 2 Table 2
11. Acknowledgements 11. References
The authors would like to thank Alexander Vainshtein, Yaakov Stein,
Erik van Veelen, Faisal Dada, Giles Heron, Luca Della Chiesa and
Ashwin Gumaste for their early contributions, review, comments and
suggestions.
Special thank you to
* Carlos Pignataro and Nagendra Kumar Nainar for giving the authors
new to IETF guidance on how to get started
* Stewart Bryant for being our shepherd
* Tal Mizahi, Joel Halpern, Christian Huitema, Tony Li, Tommy Pauly
for their reviews and suggestions during last call
* Andrew Malis and Gunter van de Velde for their guidance through
the process
12. References
12.1. Normative References 11.1. Normative References
[G.707] International Telecommunication Union (ITU), "Network node [G.707] ITU-T, "Network node interface for the synchronous digital
interface for the synchronous digital hierarchy (SDH)", hierarchy (SDH)", ITU-T Recommendation G.707, January
January 2007, <https://www.itu.int/rec/T-REC-G.707>. 2007, <https://www.itu.int/rec/T-REC-G.707>.
[G.709] International Telecommunication Union (ITU), "Interfaces [G.709] ITU-T, "Interfaces for the optical transport network",
for the optical transport network", June 2020, ITU-T Recommendation G.709, June 2020,
<https://www.itu.int/rec/T-REC-G.709>. <https://www.itu.int/rec/T-REC-G.709>.
[G.783] International Telecommunication Union (ITU), [G.783] ITU-T, "Characteristics of synchronous digital hierarchy
"Characteristics of synchronous digital hierarchy (SDH) (SDH) equipment functional blocks", ITU-T
equipment functional blocks", March 2006, Recommendation G.783, March 2006,
<https://www.itu.int/rec/T-REC-G.783>. <https://www.itu.int/rec/T-REC-G.783>.
[G.823] International Telecommunication Union (ITU), "The control [G.823] ITU-T, "The control of jitter and wander within digital
of jitter and wander within digital networks which are networks which are based on the 2048 kbit/s hierarchy",
based on the 2048 kbit/s hierarchy", March 2000, ITU-T Recommendation G.823, March 2000,
<https://www.itu.int/rec/T-REC-G.823>. <https://www.itu.int/rec/T-REC-G.823>.
[G.824] International Telecommunication Union (ITU), "The control [G.824] ITU-T, "The control of jitter and wander within digital
of jitter and wander within digital networks which are networks which are based on the 1544 kbits hierarchy",
based on the 1544 kbits hierarchy", March 2000, ITU-T Recommendation G.824, March 2000,
<https://www.itu.int/rec/T-REC-G.824>. <https://www.itu.int/rec/T-REC-G.824>.
[G.825] International Telecommunication Union (ITU), "The control [G.825] ITU-T, "The control of jitter and wander within digital
of jitter and wander within digital networks which are networks which are based on the synchronous digital
based on the synchronous digital hierarchy (SDH)", March hierarchy (SDH)", ITU-T Recommendation G.825, March 2000,
2000, <https://www.itu.int/rec/T-REC-G.825>. <https://www.itu.int/rec/T-REC-G.825>.
[G.8251] International Telecommunication Union (ITU), "The control [G.8251] ITU-T, "The control of jitter and wander within the
of jitter and wander within the optical transport network optical transport network (OTN)", ITU-T
(OTN)", November 2022, Recommendation G.8251, November 2022,
<https://www.itu.int/rec/T-REC-G.8251>. <https://www.itu.int/rec/T-REC-G.8251>.
[G.8261] International Telecommunication Union (ITU), "Timing and [G.8261] ITU-T, "Timing and synchronization aspects in packet
synchronization aspects in packet networks", August 2019, networks", ITU-T Recommendation G.8261, August 2019,
<https://www.itu.int/rec/T-REC-G.8261>. <https://www.itu.int/rec/T-REC-G.8261>.
[G.8261.1] International Telecommunication Union (ITU), "Packet delay [G.8261.1] ITU-T, "Packet delay variation network limits applicable
variation network limits applicable to packet-based to packet-based methods (Frequency synchronization)",
methods (Frequency synchronization)", February 2012, ITU-T Recommendation G.8261.1, February 2012,
<https://www.itu.int/rec/T-REC-G.8261.1>. <https://www.itu.int/rec/T-REC-G.8261.1>.
[G.8262] International Telecommunication Union (ITU), "Timing [G.8262] ITU-T, "Timing characteristics of synchronous equipment
characteristics of synchronous equipment slave clock", clocks", ITU-T Recommendation G.8262, October 2024,
November 2018, <https://www.itu.int/rec/T-REC-G.8262>. <https://www.itu.int/rec/T-REC-G.8262>.
[G.8265.1] International Telecommunication Union (ITU), "Precision [G.8265.1] ITU-T, "Precision time protocol telecom profile for
time protocol telecom profile for frequency frequency synchronization", ITU-T Recommendation G.8265.1,
synchronization", November 2022, November 2022, <https://www.itu.int/rec/T-REC-G.8265.1>.
<https://www.itu.int/rec/T-REC-G.8265.1>.
[GR253] Telcordia, "SONET Transport Systems - Common Generic [GR253] Telcordia, "Synchronous Optical Network (SONET) Transport
Criteria", October 2009, <https://telecom- Systems: Common Generic Criteria", GR-253, October 2009,
info.njdepot.ericsson.net/site-cgi/ido/ <https://telecom-info.njdepot.ericsson.net/site-cgi/ido/
docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-253>. docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-253>.
[GR499] Telcordia, "Transport Systems Generic Requirements (TSGR) [GR499] Telcordia, "Transport Systems Generic Requirements (TSGR)
- Common Requirements", November 2009, <https://telecom- - Common Requirements", GR-499, November 2009,
info.njdepot.ericsson.net/site-cgi/ido/ <https://telecom-info.njdepot.ericsson.net/site-cgi/ido/
docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-499>. docs.cgi?ID=2111701336SEARCH&DOCUMENT=GR-499>.
[I-D.draft-ietf-spring-srv6-srh-compression]
Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding (CSID)", Work
in Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-23, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-23>.
[IANA-Proto] [IANA-Proto]
IETF, "IANA "Assigned Internet Protocol Numbers" sub- IANA, "Assigned Internet Protocol Numbers",
registry", n.d., <https://www.iana.org/assignments/ <https://www.iana.org/assignments/protocol-numbers>.
protocol-numbers/protocol-numbers.xhtml#protocol-numbers-
1>.
[IANA-SRv6-End] [IANA-SRv6-End]
IETF, "IANA "SRv6 Endpoint Behaviors" sub-registry", n.d., IANA, "SRv6 Endpoint Behaviors",
<https://www.iana.org/assignments/segment-routing/segment- <https://www.iana.org/assignments/segment-routing>.
routing.xhtml#srv6-endpoint-behaviors>.
[IEEE802.3] [IEEE802.3]
IEEE, "IEEE Standard for Ethernet", May 2022, IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022,
<https://standards.ieee.org/ieee/802.3/10422/>. DOI 10.1109/IEEESTD.2022.9844436, July 2022,
<https://ieeexplore.ieee.org/document/9844436>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/rfc/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003, DOI 10.17487/RFC3551, July 2003,
<https://www.rfc-editor.org/rfc/rfc3551>. <https://www.rfc-editor.org/info/rfc3551>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005, DOI 10.17487/RFC3985, March 2005,
<https://www.rfc-editor.org/rfc/rfc3985>. <https://www.rfc-editor.org/info/rfc3985>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/rfc/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986, (SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021, DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/rfc/rfc8986>. <https://www.rfc-editor.org/info/rfc8986>.
[RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene, [RFC9252] Dawra, G., Ed., Talaulikar, K., Ed., Raszuk, R., Decraene,
B., Zhuang, S., and J. Rabadan, "BGP Overlay Services B., Zhuang, S., and J. Rabadan, "BGP Overlay Services
Based on Segment Routing over IPv6 (SRv6)", RFC 9252, Based on Segment Routing over IPv6 (SRv6)", RFC 9252,
DOI 10.17487/RFC9252, July 2022, DOI 10.17487/RFC9252, July 2022,
<https://www.rfc-editor.org/rfc/rfc9252>. <https://www.rfc-editor.org/info/rfc9252>.
12.2. Informative References [RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding (CSID)",
RFC 9800, DOI 10.17487/RFC9800, June 2025,
<https://www.rfc-editor.org/info/rfc9800>.
11.2. Informative References
[ATIS-0900105.09.2013] [ATIS-0900105.09.2013]
ATIS, "Synchronous Optical Network (SONET) - Network ATIS, "Synchronous Optical Network (SONET) - Network
Element Timing and Synchronization", 2013, Element Timing and Synchronization", ATIS-
0900105.09.2013(S2023), 2023,
<https://webstore.ansi.org/standards/atis/ <https://webstore.ansi.org/standards/atis/
atis0900105092013s2023>. atis0900105092013s2023>.
[EVPN-VPWS]
Gringeri, S., Whittaker, J., Schmutzer, C., Ed.,
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>.
[FC-PI-2] INCITS, "Information Technology - Fibre Channel Physical [FC-PI-2] INCITS, "Information Technology - Fibre Channel Physical
Interfaces - 2 (FC-PI-2)", 2006, Interfaces - 2 (FC-PI-2)", INCITS 404-2006 (S2016), 2016,
<https://webstore.ansi.org/standards/incits/ <https://webstore.ansi.org/standards/incits/
incits4042006>. incits4042006s2016>.
[FC-PI-5] INCITS, "Information Technology - Fibre Channel - Physical [FC-PI-5] INCITS, "Information Technology - Fibre Channel - Physical
Interface-5 (FC-PI-5)", 2011, Interface-5 (FC-PI-5)", INCITS 479-2011, 2011,
<https://webstore.ansi.org/standards/incits/ <https://webstore.ansi.org/standards/incits/
incits4792011>. incits4792011>.
[FC-PI-5am1] [FC-PI-5am1]
INCITS, "Information Technology - Fibre Channel - Physical INCITS, "Information Technology - Fibre Channel - Physical
Interface - 5/Amendment 1 (FC-PI-5/AM1)", 2016, Interface - 5/Amendment 1 (FC-PI-5/AM1)",
INCITS 479-2011/AM1-2016, 2016,
<https://webstore.ansi.org/standards/incits/ <https://webstore.ansi.org/standards/incits/
incits4792011am12016>. incits4792011am12016>.
[FC-PI-6] INCITS, "Information Technology - Fibre Channel - Physical [FC-PI-6] INCITS, "Information Technology - Fibre Channel - Physical
Interface - 6 (FC-PI-6)", 2015, Interface - 6 (FC-PI-6)", INCITS 512-2015, 2015,
<https://webstore.ansi.org/standards/incits/ <https://webstore.ansi.org/standards/incits/
incits5122015>. incits5122015>.
[FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical [FC-PI-6P] INCITS, "Information Technology - Fibre Channel - Physical
Interface - 6P (FC-PI-6P)", 2016, Interface - 6P (FC-PI-6P)", INCITS 533-2016, 2016,
<https://webstore.ansi.org/standards/incits/ <https://webstore.ansi.org/standards/incits/
incits5332016>. incits5332016>.
[FC-PI-7] INCITS, "Information Technology – Fibre Channel - Physical [FC-PI-7] ISO/IEC, "Information technology – Fibre channel - Part
Interfaces - 7 (FC-PI-7)", 2021, 147: Physical interfaces - 7 (FC-PI-7)", ISO/
<https://webstore.ansi.org/standards/iso/ IEC 14165-147:2021, 2021,
isoiec141651472021>. <https://www.iso.org/standard/80933.html>.
[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>.
[I-D.draft-schmutzer-bess-bitstream-vpws-signalling] [G.826] ITU-T, "End-to-end error performance parameters and
Gringeri, S., Whittaker, J., Schmutzer, C., Vasudevan, B., objectives for international, constant bit-rate digital
and P. Brissette, "Ethernet VPN Signalling Extensions for paths and connections", ITU-T Recommendation G.826,
Bit-stream VPWS", Work in Progress, Internet-Draft, draft- December 2002, <https://www.itu.int/rec/T-REC-G.826>.
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] [LDP-PLE] Schmutzer, C., Ed., "LDP Extensions to Support Private
Schmutzer, C., "LDP Extensions to Support Private Line Line Emulation (PLE)", Work in Progress, Internet-Draft,
Emulation (PLE)", Work in Progress, Internet-Draft, draft- draft-schmutzer-pals-ple-signaling-02, 20 October 2024,
schmutzer-pals-ple-signaling-02, 20 October 2024,
<https://datatracker.ietf.org/doc/html/draft-schmutzer- <https://datatracker.ietf.org/doc/html/draft-schmutzer-
pals-ple-signaling-02>. pals-ple-signaling-02>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/rfc/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Label Switching Architecture", RFC 3031,
DOI 10.17487/RFC3031, January 2001, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/rfc/rfc3031>. <https://www.rfc-editor.org/info/rfc3031>.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of [RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, DOI 10.17487/RFC3086, their Specification", RFC 3086, DOI 10.17487/RFC3086,
April 2001, <https://www.rfc-editor.org/rfc/rfc3086>. April 2001, <https://www.rfc-editor.org/info/rfc3086>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/rfc/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le [RFC3246] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D. Boudec, J.Y., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<https://www.rfc-editor.org/rfc/rfc3246>. <https://www.rfc-editor.org/info/rfc3246>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/rfc/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation
of Time Division Multiplexed (TDM) Circuits over Packet of Time Division Multiplexed (TDM) Circuits over Packet
Switching Networks", RFC 4197, DOI 10.17487/RFC4197, Switching Networks", RFC 4197, DOI 10.17487/RFC4197,
October 2005, <https://www.rfc-editor.org/rfc/rfc4197>. October 2005, <https://www.rfc-editor.org/info/rfc4197>.
[RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP [RFC4381] Behringer, M., "Analysis of the Security of BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4381, Virtual Private Networks (VPNs)", RFC 4381,
DOI 10.17487/RFC4381, February 2006, DOI 10.17487/RFC4381, February 2006,
<https://www.rfc-editor.org/rfc/rfc4381>. <https://www.rfc-editor.org/info/rfc4381>.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385,
February 2006, <https://www.rfc-editor.org/rfc/rfc4385>. February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/rfc/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS "Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/rfc/rfc4448>. <https://www.rfc-editor.org/info/rfc4448>.
[RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006,
<https://www.rfc-editor.org/rfc/rfc4553>. <https://www.rfc-editor.org/info/rfc4553>.
[RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"Synchronous Optical Network/Synchronous Digital Hierarchy "Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) Circuit Emulation over Packet (CEP)", (SONET/SDH) Circuit Emulation over Packet (CEP)",
RFC 4842, DOI 10.17487/RFC4842, April 2007, RFC 4842, DOI 10.17487/RFC4842, April 2007,
<https://www.rfc-editor.org/rfc/rfc4842>. <https://www.rfc-editor.org/info/rfc4842>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/rfc/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC4906] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed., [RFC4906] Martini, L., Ed., Rosen, E., Ed., and N. El-Aawar, Ed.,
"Transport of Layer 2 Frames Over MPLS", RFC 4906, "Transport of Layer 2 Frames Over MPLS", RFC 4906,
DOI 10.17487/RFC4906, June 2007, DOI 10.17487/RFC4906, June 2007,
<https://www.rfc-editor.org/rfc/rfc4906>. <https://www.rfc-editor.org/info/rfc4906>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/rfc/rfc5036>. October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-Aware Time Division Multiplexed (TDM) P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
Circuit Emulation Service over Packet Switched Network Circuit Emulation Service over Packet Switched Network
(CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007,
<https://www.rfc-editor.org/rfc/rfc5086>. <https://www.rfc-editor.org/info/rfc5086>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/rfc/rfc5920>. <https://www.rfc-editor.org/info/rfc5920>.
[RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic [RFC7212] Frost, D., Bryant, S., and M. Bocci, "MPLS Generic
Associated Channel (G-ACh) Advertisement Protocol", Associated Channel (G-ACh) Advertisement Protocol",
RFC 7212, DOI 10.17487/RFC7212, June 2014, RFC 7212, DOI 10.17487/RFC7212, June 2014,
<https://www.rfc-editor.org/rfc/rfc7212>. <https://www.rfc-editor.org/info/rfc7212>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/rfc/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)", Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/rfc/rfc8077>. <https://www.rfc-editor.org/info/rfc8077>.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J.
Rabadan, "Virtual Private Wire Service Support in Ethernet Rabadan, "Virtual Private Wire Service Support in Ethernet
VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017,
<https://www.rfc-editor.org/rfc/rfc8214>. <https://www.rfc-editor.org/info/rfc8214>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/rfc/rfc8754>. <https://www.rfc-editor.org/info/rfc8754>.
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, [RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker,
"Deterministic Networking (DetNet) Security "Deterministic Networking (DetNet) Security
Considerations", RFC 9055, DOI 10.17487/RFC9055, June Considerations", RFC 9055, DOI 10.17487/RFC9055, June
2021, <https://www.rfc-editor.org/rfc/rfc9055>. 2021, <https://www.rfc-editor.org/info/rfc9055>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, [RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture", A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022, RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/rfc/rfc9256>. <https://www.rfc-editor.org/info/rfc9256>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>. <https://www.rfc-editor.org/info/rfc9293>.
[T11] INCITS, "T11 - Fibre Channel", n.d., [T11] INCITS, "T11 - Fibre Channel",
<https://www.incits.org/committees/t11>. <https://www.incits.org/committees/t11>.
Acknowledgements
The authors would like to thank Alexander Vainshtein, Yaakov Stein,
Erik van Veelen, Faisal Dada, Giles Heron, Luca Della Chiesa, and
Ashwin Gumaste for their early contributions, review, comments, and
suggestions.
Special thank you to:
* Carlos Pignataro and Nagendra Kumar Nainar for giving the authors
new-to-the-IETF guidance on how to get started
* Stewart Bryant for being our shepherd
* Tal Mizahi, Joel Halpern, Christian Huitema, Tony Li, and Tommy
Pauly for their reviews and suggestions during Last Call
* Andrew Malis and Gunter van de Velde for their guidance through
the process
Contributors Contributors
Andreas Burk Andreas Burk
1&1 Versatel 1&1 Versatel
Email: andreas.burk@magenta.de Email: andreas.burk@magenta.de
Faisal Dada Faisal Dada
AMD AMD
Email: faisal.dada@amd.com Email: faisal.dada@amd.com
 End of changes. 377 change blocks. 
728 lines changed or deleted 710 lines changed or added

This html diff was produced by rfcdiff 1.48.