Verizon

steven.gringeri@verizon.com

Verizon

jeremy.whittaker@verizon.com

Deutsche Telekom

N.Leymann@telekom.de

Cisco Systems, Inc.

cschmutz@cisco.com

Ciena Corporation

cbrown@ciena.com

RTG pals This document expands the applicability of Virtual Private Wire Service (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over Packet Switched Networks (PSNs).

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction and Motivation
• .  Requirements Notation
• .  Terminology and Reference Models
  • .  Abbreviations
  • .  Reference Models
• .  Emulated Services
  • .  Generic PLE Service
  • .  Ethernet Services
    • .  1000BASE-X
    • .  10GBASE-R and 25GBASE-R
    • .  40GBASE-R, 50GBASE-R, and 100GBASE-R
    • .  200GBASE-R and 400GBASE-R
    • .  Energy Efficient Ethernet (EEE)
  • .  SONET/SDH Services
  • .  Fibre Channel Services
    • .  1GFC, 2GFC, 4GFC, and 8GFC
    • .  16GFC
    • .  32GFC and 4-Lane 128GFC
    • .  64GFC
  • .  OTN Services
• .  PLE Encapsulation Layer
  • .  PSN and VPWS Demultiplexing Headers
    • .  New SRv6 Behaviors
  • .  PLE Header
    • .  PLE Control Word
    • .  RTP Header
• .  PLE Payload Layer
  • .  Basic Payload
  • .  Byte-Aligned Payload
• .  PLE Operation
  • .  Common Considerations
  • .  PLE IWF Operation
    • .  PSN-Bound Encapsulation Behavior
    • .  CE-Bound Decapsulation Behavior
  • .  PLE Performance Monitoring
  • .  PLE Fault Management
• .  QoS and Congestion Control
• .  Security Considerations
• . IANA Considerations
  • .  Bit-Stream Next Header Type
  • .  SRv6 Endpoint Behaviors
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction and Motivation This document describes a method called Private Line Emulation (PLE) for encapsulating not only Time Division Multiplexing (TDM) signals as bit-stream Virtual Private Wire Service (VPWS) over Packet Switched Networks (PSN). In this regard, it complements methods described in . This emulation suits applications, where carrying Protocol Data Units (PDUs) as defined in or is not enough, physical layer signal transparency is required and data or framing structure interpretation of the Provider Edge (PE) would be counterproductive. One example of such case is two Ethernet-connected Customer Edge (CE) devices and the need for Synchronous Ethernet operation (see ) between them without the intermediate PE devices interfering or addressing concerns about Ethernet control protocol transparency for PDU-based carrier Ethernet services, beyond the behavior definitions of MEF Forum (MEF) specifications. Another example would be a Storage Area Networking (SAN) extension between two data centers. Operating at a bit-stream level allows for a connection between Fibre Channel switches without interfering with any of the Fibre Channel protocol mechanisms defined by . Also, SONET/SDH (Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)) add/drop multiplexers or cross-connects can be interconnected without interfering with the multiplexing structures and networks mechanisms. This is a key distinction to Circuit Emulation over Packet (CEP) defined in where multiplexing and demultiplexing is desired in order to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC). In other words, PLE provides an independent layer network underneath the SONET/SDH layer 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 to Structure-Agnostic TDM over Packet (SAToP) (defined in ). The applicability is expanded beyond the narrow set of Plesiochronous Digital Hierarchy (PDH) interfaces (T1, E1, T3, and E3) to allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH ( / ), and Optical Transport Network (OTN) at gigabit speeds. The signals are treated as bit-stream payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in Sections and of .

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology and Reference Models

Abbreviations

ACH:

Associated Channel Header

AIS:

Alarm Indication Signal

AIS-L:

Line AIS

MS-AIS:

Multiplex Section AIS

BITS:

Building Integrated Timing Supply

CBR:

Constant Bit Rate

CE:

Customer Edge

CEP:

Circuit Emulation over Packet

CSID:

Compressed SID

CSRC:

Contributing Source

DEG:

Degradation

ES:

Errored Second

FEC:

Forward Error Correction

ICMP:

Internet Control Message Protocol

IEEE:

Institute of Electrical and Electronics Engineers

INCITS:

INternational Committee for Information Technology Standards

IWF:

Interworking Function

LDP:

Label Distribution Protocol ,

LF:

Local Fault

LOF:

Loss Of Frame

LOM:

Loss Of Multiframe

LOS:

Loss Of Signal

LPI:

Low Power Idle

LSP:

Label Switched Path

MEF:

MEF Forum

MPLS:

Multiprotocol Label Switching

NOS:

Not Operational

NSP:

Native Service Processing

ODUk:

Optical Data Unit k

OOF:

Out Of Frame

OTN:

Optical Transport Network

OTUk:

Optical Transport Unit k

PCS:

Physical Coding Sublayer

PDV:

Packet Delay Variation

PE:

Provider Edge

PLE:

Private Line Emulation

PLOS:

Packet Loss Of Signal

PLR:

Packet Loss Rate

PMA:

Physical Medium Attachment

PMD:

Physical Medium Dependent

PSN:

Packet Switched Network

PTP:

Precision Time Protocol

PW:

Pseudowire

PWE3:

Pseudo Wire Emulation Edge-to-Edge

RDI:

Remote Defect Indication

RSVP-TE:

Resource Reservation Protocol Traffic Engineering

RTCP:

RTP Control Protocol

RTP:

Real-time Transport Protocol

SD:

Signal Degrade

SES:

Severely Errored Seconds

SDH:

Synchronous Digital Hierarchy

SID:

Segment Identifier

SR:

Segment Routing

SRH:

Segment Routing Header

SRTP:

Secure Real-time Transport Protocol

SRv6:

Segment Routing over IPv6

SSRC:

Synchronization Source

SONET:

Synchronous Optical Network

TCP:

Transmission Control Protocol

TDM:

Time Division Multiplexing

TTS:

Transmitter Training Signal

UAS:

Unavailable Seconds

VPWS:

Virtual Private Wire Service

Reference Models The reference model for PLE is illustrated in and is inline with the reference model defined in . PLE relies on PWE3 preprocessing, in particular the concept of an NSP function defined in .

PLE Reference Model |<--- p2p L2VPN service -->| | | | |<-PSN tunnel->| | v v v v +---------+ +---------+ | PE1 |==============| PE2 | +---+-----+ +-----+---+ +-----+ | N | | | | N | +-----+ | CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 | +-----+ ^ | P | | | | P | ^ +-----+ | +---+-----+ +-----+---+ | CE1 physical ^ ^ CE2 physical interface | | interface |<--- emulated service --->| | | attachment attachment circuit circuit

PLE embraces the minimum intervention principle outlined in , which means the data is flowing through the PLE encapsulation layer as received without modifications. For some service types, the NSP function is responsible for performing operations on the data received from the CE. Examples are terminating FEC, terminating the OTUk layer for OTN, or dealing with multi-lane processing. After the NSP, the IWF is generating the payload of the VPWS, which is carried via a PSN tunnel. To allow the clock of the transported signal to be carried across the PLE domain in a transparent way, the relative network synchronization reference model and deployment scenario outlined in are applicable and are shown in .

Relative Network Scenario Timing J | G | | | +-----+ +-----+ v +-----+ v |- - -|=================|- - -| +-----+ | |<---------|.............................|<---------| | | CE1 | | PE1 | VPWS | PE2 | | CE2 | | |--------->|.............................|--------->| | +-----+ |- - -|=================|- - -| ^ +-----+ ^ +-----+ +-----+ | | ^ C D ^ | A | | | +-----------+-----------+ E | +-+ |I| +-+

The local oscillators C of PE1 and D of PE2 are locked to a common clock I. The attachment circuit clock E is generated by PE2 via a differential clock recovery method in reference to the common clock I. For this to work, the difference between clock A and clock C (locked to I) MUST be explicitly transferred from PE1 to PE2 using the timestamp inside the RTP header. For the reverse direction, PE1 generates the attachment circuit clock J and the clock difference between G and D (locked to I) is transferred from PE2 to PE1. The method used to lock clocks C and D to the common clock I is out of scope of this document; however, there are already several well-established concepts for achieving clock synchronization (commonly also referred to as "frequency synchronization") available. While using external timing inputs (aka BITS ) or synchronous Ethernet (as defined in ), the characteristics and limits defined in have to be considered. While relying on PTP (as defined in ), the network limits defined in have to be considered.

Emulated Services This specification describes the emulation of services from a wide range of technologies, such as TDM, Ethernet, Fibre Channel, or OTN, as bit-streams or structured bit-streams, as defined in Sections and of .

Generic PLE Service The generic PLE service is an example of the bit-stream defined in . Under the assumption that the CE-bound IWF is not responsible for any service-specific operation, a bit-stream of any rate can be carried using the generic PLE payload. There is no NSP function present for this service.

Ethernet Services Ethernet services are special cases of the structured bit-stream defined in . The IEEE has defined several layers for Ethernet in . Emulation is operating at the physical (PHY) layer, more precisely at the PCS. Over time, many different Ethernet interface types have been specified in with a varying set of characteristics, such as optional versus mandatory FEC and single-lane versus multi-lane transmission. Ethernet interface types with backplane PMD variants and Ethernet interface types mandating auto-negotiation (except 1000Base-X) are out of scope for this document. All Ethernet services are leveraging the basic PLE payload and interface-specific mechanisms are confined to the respective service specific NSP functions.

1000BASE-X The PCS layer of 1000BASE-X (defined in Section 36 of ) is based on 8B/10B code. The PSN-bound NSP function does not modify the received data and is transparent to auto-negotiation; however, it is responsible for detecting attachment circuit faults specific to 1000BASE-X such as LOS and sync loss. When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function MAY disable its transmitter as no appropriate maintenance signal was defined for 1000BASE-X by the IEEE.

10GBASE-R and 25GBASE-R The PCS layers of 10GBASE-R (defined in Section 49 and 25GBASE-R defined in Section 107 of ) are based on a 64B/66B code. Sections 74 and 108 of define an optional FEC layer; if present, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function MUST generate the FEC. The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 10GBASE-R and 25GBASE-R such as LOS and sync loss. The PSN-bound IWF maps the scrambled 64B/66B code stream into the basic PLE payload. The CE-bound NSP function MUST perform:

• PCS code sync (Section 49.2.9 of ) and
• descrambling (Section 49.2.10 of )

in order to properly:

• transform invalid 66B code blocks into proper error control characters /E/ (Section 49.2.4.11 of ) and
• insert LF ordered sets (Section 46.3.4 of ) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

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

40GBASE-R, 50GBASE-R, and 100GBASE-R The PCS layers of 40GBASE-R and 100GBASE-R (defined in Section 82 of ) and of 50GBASE-R (defined in Section 133 of ) are based on a 64B/66B code transmitted over multiple lanes. Sections 74 and 91 of define an optional FEC layer; if present, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function MUST generate the FEC. To gain access to the scrambled 64B/66B code stream, the PSN-bound NSP further MUST perform:

• block synchronization (Section 82.2.12 of ),
• PCS lane de-skew (Section 82.2.13 of ), and
• PCS lane reordering (Section 82.2.14 of ).

The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 40GBASE-R, 50GBASE-R, and 100GBASE-R such as LOS and loss of alignment. The PSN-bound IWF maps the serialized and scrambled 64B/66B code stream including the alignment markers into the basic PLE payload. The CE-bound NSP function MUST perform:

• PCS code sync (Section 82.2.12 of ),
• alignment-marker removal (Section 82.2.15 of ), and
• descrambling (Section 49.2.10 of )

in order to properly:

• transform invalid 66B code blocks into proper error control characters /E/ (Section 82.2.3.10 of ) and
• insert LF ordered sets (Section 81.3.4 of ) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

• scrambling of the 64B/66B code (Section 49.2.6 of ),
• block distribution (Section 82.2.6 of ), and
• alignment-marker insertion (Sections 82.2.7 and 133.2.2 of ).

200GBASE-R and 400GBASE-R The PCS layers of 200GBASE-R and 400GBASE-R (defined in Section 119 of ) are based on a 64B/66B code transcoded to a 256B/257B code to reduce the overhead and make room for a mandatory FEC. To gain access to the 64B/66B code stream, the PSN-bound NSP further MUST perform:

• alignment lock and de-skew (Section 119.2.5.1 of ),
• PCS lane reordering and de-interleaving (Section 119.2.5.2 of ),
• FEC decoding (Section 119.2.5.3 of ),
• post-FEC interleaving (Section 119.2.5.4 of ),
• alignment-marker removal (Section 119.2.5.5 of ),
• descrambling (Section 119.2.5.6 of ), and
• reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of ).

Further, the PSN-bound NSP MUST perform rate compensation and scrambling (Section 49.2.6 of ) before the PSN-bound IWF maps the same into the basic PLE payload. Rate compensation is applied so that the rate of the 66B encoded bit-stream carried by PLE is 528/544 times the nominal bitrate of the 200GBASE-R or 400GBASE-R at the PMA service interface. X number of 66-byte-long rate compensation blocks are inserted every X*20479 number of 66B client blocks. For 200GBASE-R, the value of X is 16; for 400GBASE-R, the value of X is 32. Rate compensation blocks are special 66B control characters of type 0x00 that can easily be searched for by the CE-bound IWF in order to remove them. The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to 200GBASE-R and 400GBASE-R such as LOS and loss of alignment. The CE-bound NSP function MUST perform:

• PCS code sync (Section 49.2.13 of ),
• descrambling (Section 49.2.10 of ), and
• rate compensation block removal

in order to properly:

• transform invalid 66B code blocks into proper error control characters /E/ (Section 119.2.3.9 of ) and
• insert LF ordered sets (Section 81.3.4 of ) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

• transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of ),
• scrambling (Section 119.2.4.3 of ),
• alignment-marker insertion (Section 119.2.4.4 of ),
• pre-FEC distribution (Section 119.2.4.5 of ),
• FEC encoding (Section 119.2.4.6 of ), and
• PCS lane distribution (Section 119.2.4.8 of ).

Energy Efficient Ethernet (EEE) Section 78 of defines the optional LPI capability for Ethernet. Two modes are defined:

• deep sleep
• fast wake

Deep sleep mode is not compatible with PLE due to the CE ceasing transmission. Hence, there is no support for LPI for 10GBASE-R services across PLE. In fast wake mode, the CE transmits /LI/ control code blocks instead of /I/ control code blocks and, therefore, PLE is agnostic to it. For 25GBASE-R and higher services across PLE, LPI is supported as only fast wake mode is applicable.

SONET/SDH Services SONET/SDH services are special cases of the structured bit-stream defined in . SDH interfaces are defined in ; SONET interfaces are defined in . The PSN-bound NSP function does not modify the received data but is responsible for detecting attachment circuit faults specific to SONET/SDH such as LOS, LOF, and OOF. Data received by the PSN-bound IWF is mapped into the basic PLE payload without any awareness of SONET/SDH frames. When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the:

• MS-AIS maintenance signal (defined in Section 6.2.4.1.1 of ) for SDH services and
• AIS-L maintenance signal (defined in Section 6.2.1.2 of ) for SONET services

at client-frame boundaries.

Fibre Channel Services Fibre Channel services are special cases of the structured bit-stream defined in . The T11 technical committee of INCITS has defined several layers for Fibre Channel. PLE operates at the FC-1 layer that leverages mechanisms defined by . Over time, many different Fibre Channel interface types have been specified with a varying set of characteristics such as optional versus mandatory FEC and single-lane versus multi-lane transmission. Speed negotiation is not supported by PLE. All Fibre Channel services leverage the basic PLE payload, and interface-specific mechanisms are confined to the respective service-specific NSP functions.

1GFC, 2GFC, 4GFC, and 8GFC specifies 1GFC and 2GFC. and define 4GFC and 8GFC. The PSN-bound NSP function is responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss. The PSN-bound IWF maps the received 8B/10B code stream as is directly into the basic PLE payload. The CE-bound NSP function MUST perform transmission word sync in order to properly:

• replace invalid transmission words with the special character K30.7 and
• insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

defines the use of scrambling for 8GFC; in this case, the CE-bound NSP MUST also perform descrambling before replacing invalid transmission words or inserting NOS ordered sets. Before sending the bit-stream to the CE, the CE-bound NSP function MUST scramble the 8B/10B code stream.

16GFC and specify 16GFC and define an optional FEC layer. If FEC is present, it must be indicated via TTS when the attachment circuit is brought up. Further, the PSN-bound NSP function MUST terminate the FEC and the CE-bound NSP function must generate the FEC. The PSN-bound NSP function is responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss. The PSN-bound IWF maps the received scrambled 64B/66B code stream as is into the basic PLE payload. The CE-bound NSP function MUST perform:

• transmission word sync (Section 49.2.13 of ) and
• descrambling (Section 49.2.10 of )

in order to properly:

• replace invalid transmission words with the error transmission word 1Eh and
• insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

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

32GFC and 4-Lane 128GFC specifies 32GFC and specifies 4-lane 128GFC, both with FEC layer and TTS support being mandatory. To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform:

• descrambling (Section of 49.2.10 of ),
• FEC decoding (Section 91.5.3.3 of ), and
• reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5.7 of ).

Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of ) before the PSN-bound IWF maps the same into the basic PLE payload. The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss. The CE-bound NSP function MUST perform:

• transmission word sync (Section 119.2.6.3 of ) and
• descrambling (Section 49.2.10 of )

in order to properly:

• replace invalid transmission words with the error transmission word 1Eh and
• insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

• transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of ),
• FEC encoding (Section 91.5.2.7 of ), and
• scrambling (Section 49.2.6 of ).

64GFC specifies 64GFC with a mandatory FEC layer. To gain access to the 64B/66B code stream, the PSN-bound NSP further MUST perform:

• alignment lock (Section 134.5.4 of modified to single FEC lane operation),
• FEC decoding (Section 134.5.3.3 of ),
• alignment-marker removal (Section 134.5.3.4 of ), and
• reverse transcoding from 256B/257B to 64B/66B (Section 91.5.3.5 of ).

Further, the PSN-bound NSP MUST perform scrambling (Section 49.2.6 of ) before the PSN-bound IWF maps the same into the basic PLE payload. The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to the Fibre Channel such as LOS and sync loss. The CE-bound NSP function MUST perform:

• transmission word sync (Section 49.2.13 of ) and
• descrambling (Section 49.2.10 of )

in order to properly:

• replace invalid transmission words with the error transmission word 1Eh and
• insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.

When sending the bit-stream to the CE, the CE-bound NSP function MUST also perform:

• transcoding from 64B/66B to 256B/257B (Section 91.5.2.5 of ),
• alignment-marker insertion (Section 134.5.2.6 of ), and
• FEC encoding (Section 134.5.2.7 of ).

OTN Services OTN services are special cases of the structured bit-stream defined in . OTN interfaces are defined in . The PSN-bound NSP function MUST terminate the FEC and replace the OTUk overhead in row 1, columns 8-14 with an all-zeros pattern; this results in an extended ODUk frame as illustrated in . The frame alignment overhead (FA OH) in row 1, columns 1-7 is kept as it is.

Extended ODUk Frame column # 1 7 8 14 15 3824 +--------+--------+------------------- .. --------------------+ 1| FA OH | All-0s | | +--------+--------+ | r 2| | | o | | | w 3| ODUk overhead | | # | | | 4| | | +-----------------+------------------- .. --------------------+

The PSN-bound NSP function is also responsible for detecting attachment circuit faults specific to OTUk such as LOS, LOF, LOM, and AIS. The PSN-bound IWF maps the extended ODUk frame into the byte-aligned PLE payload. The CE-bound NSP function will recover the ODUk by searching for the frame alignment overhead in the extended ODUk received from the CE-bound IWF and generating the FEC. When the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set, the CE-bound NSP function is responsible for generating the ODUk-AIS maintenance signal defined in Section 16.5.1 of at client-frame boundaries.

PLE Encapsulation Layer The basic packet format used by PLE is shown in .

PLE Encapsulation Layer +-------------------------------+ -+ | PSN and VPWS Demux | \ | (MPLS/SRv6) | > PSN and VPWS | | / Demux Headers +-------------------------------+ -+ | PLE Control Word | \ +-------------------------------+ > PLE Header | RTP Header | / +-------------------------------+ --+ | Bit-Stream | \ | Payload | > Payload | | / +-------------------------------+ --+

PSN and VPWS Demultiplexing Headers This document does not suggest any specific technology be used for implementing the VPWS demultiplexing and PSN layers. The total size of a PLE packet for a specific PW MUST NOT exceed the path MTU between the pair of PEs terminating this PW. When an MPLS PSN layer is used, a VPWS label provides the demultiplexing mechanism (as described in ). The PSN tunnel can be a simple best-path LSP established using LDP (see ) or Segment Routing (SR) (see ); or it can be a traffic-engineered LSP established using RSVP-TE (see ) or SR policies (see ). When an SRv6 PSN layer is used, an SRv6 service SID (as defined in ) provides the demultiplexing mechanism and definitions of apply. Both SRv6 service SIDs with the full IPv6 address format defined in and CSIDs with the format defined in can be used.

New SRv6 Behaviors Two new encapsulation behaviors, H.Encaps.L1 and H.Encaps.L1.Red, are defined in this document. The behavior procedures are applicable to both SIDs and CSIDs. The H.Encaps.L1 behavior encapsulates a frame received from an IWF in an IPv6 packet with a segment routing header (SRH). The received frame becomes the payload of the new IPv6 packet.

• The next header field of the SRH or the last extension header present MUST be set to 147.
• The insertion of the SRH MAY be omitted per when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.

The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.

• H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH. The first SID is only placed in the Destination Address field of the IPv6 header.
• The insertion of the SRH MAY be omitted per when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.

Three new "Endpoint with decapsulation and bit-stream cross-connect" behaviors called "End.DX1", "End.DX1 with NEXT-CSID", and "End.DX1 with REPLACE-CSID" are defined in this document. These new behaviors are variants of End.DX2 defined in , and they all have the following procedures in common: The End.DX1 SID MUST be the last segment in an SR Policy, and it is associated with a CE-bound IWF I. When N receives a packet destined to S and S is a local End.DX1 SID, N does the following: S01. When an SRH is processed { S02. If (Segments Left != 0) { S03. Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S04. } S05. Proceed to process the next header in the packet S06. } When processing the next (Upper-Layer) header of a packet matching a FIB entry locally instantiated as an End.DX1 SID, N does the following: S01. If (Upper-Layer header type == 147 (bit-stream) ) { S02. Remove the outer IPv6 header with all its extension headers S03. Forward the remaining frame to the IWF I S04. } Else { S05. Process as per {{Section 4.1.1 of RFC 8986}} S06. }

PLE Header The PLE header MUST contain the PLE control word (4 bytes) and MUST include a fixed-size RTP header . The RTP header MUST immediately follow the PLE control word.

PLE Control Word The format of the PLE control word is in line with the guidance in and is shown in .

PLE Control Word 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The bits 0..3 of the first nibble are set to 0 to differentiate a control word or ACH from an IP packet or Ethernet frame. The first nibble MUST be set to 0000b to indicate that this header is a control word as defined in . The other fields in the control word are used as defined below:

L:

Set by the PE to indicate that data carried in the payload is invalid due to an attachment circuit fault. The downstream PE MUST send appropriate replacement data. The NSP MAY inject an appropriate downstream fault-indication signal.

R:

Set by the downstream PE to indicate that the IWF experiences packet loss from the PSN or a server layer backward fault indication is present in the NSP. The R bit MUST be cleared by the PE once the packet loss state or fault indication has cleared.

RSV:

These bits are reserved for future use. This field MUST be set to zero by the sender and ignored by the receiver.

FRG:

These bits MUST be set to zero by the sender and ignored by the receiver as PLE does not use payload fragmentation.

LEN:

In accordance with , the length field MUST always be set to zero as there is no padding added to the PLE packet. The size of the PLE payload MUST be assumed to be as described in ; if the actual packet size is inconsistent with this, the packet MUST be considered malformed.

Sequence number:

The sequence number field is used to provide a common PW sequencing function as well as detection of lost packets. It MUST be generated in accordance with the rules defined in and MUST be incremented with every PLE packet being sent.

RTP Header The RTP header MUST be included to explicitly convey timing information. The RTP header (as defined in ) is reused to align with other bit-stream emulation pseudowires defined by , , and and to allow PLE implementations to reuse preexisting work. There is no intention to support full RTP topologies and protocol mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTCP, RTP header compression, SRTP, etc., as these are not applicable to PLE VPWS. The format of the RTP header is as shown in .

RTP Header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Synchronization Source (SSRC) Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

V:

Version The version field MUST be set to 2.

P:

Padding The padding flag MUST be set to zero by the sender and ignored by the receiver.

X:

Header extension The X bit MUST be set to zero by sender and ignored by receiver.

CC:

CSRC count The CC field MUST be set to zero by the sender and ignored by the receiver.

M:

Marker The M bit MUST be set to zero by the sender and ignored by the receiver.

PT:

Payload type A PT value MUST be allocated from the range of dynamic values defined in for each direction of the VPWS. The same PT value MAY be reused for both for directions and between different PLE VPWSs. The PT field MAY be used for detection of misconnections.

Sequence number:

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 control word. When using a sequence number space of 32 bits, the initial value of the RTP sequence number MUST be 0 and incremented whenever the PLE control word sequence number cycles through from 0xFFFF to 0x0000.

Timestamp:

Timestamp values are used in accordance with the rules established in . For bit-streams up to 200 Gbps, the frequency of the clock used for generating timestamps MUST be 125 MHz based on a the common clock I. For bit-streams above 200 Gbps, the frequency MUST be 250 MHz.

SSRC:

Synchronization source The SSRC field MAY be used for detection of misconnections.

PLE Payload Layer A bit-stream is mapped into a PLE packet with a fixed payload size, which MUST be defined during VPWS setup, MUST be the same in both directions of the VPWS, and MUST remain unchanged for the lifetime of the VPWS. All PLE implementations MUST be capable of supporting the default payload size of 1024 bytes. The payload size SHOULD be configurable to be able to address specific packetization delay and overhead expectations. The smallest supported payload size is 64 bytes.

Basic Payload The PLE payload is filled with incoming bits of the bit-stream starting from the most significant to the least significant bit without considering any structure of the bit-stream.

Byte-Aligned Payload The PLE payload is filled in a byte-aligned manner, where the order of the payload bytes corresponds to their order on the attachment circuit. Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant. The PLE payload size MUST be an integer number of bytes.

PLE Operation

Common Considerations A PLE VPWS can be established using manual configuration or leveraging mechanisms of a signaling protocol. Furthermore, emulation of bit-stream signals using PLE is only possible when the two attachment circuits of the VPWS are of the same service type (OC192, 10GBASE-R, ODU2, etc.) and are using the same PLE payload type and payload size. This can be ensured via manual configuration or via the mechanisms of a signaling protocol. PLE-related control protocol extensions to LDP or EVPN-VPWS are out of scope for this document. Extensions for EVPN-VPWS are proposed in and for LDP in .

PLE IWF Operation

PSN-Bound Encapsulation Behavior After the VPWS is set up, the PSN-bound IWF performs the following steps:

• Packetize the data received from the CE into PLE payloads, all of the same configured size,
• Add PLE control word and RTP header with sequence numbers, flags, and timestamps properly set,
• Add the VPWS demultiplexer and PSN headers,
• Transmit the resulting packets over the PSN,
• Set the L bit in the PLE control word whenever the attachment circuit detects a fault, and
• Set the R bit in the PLE control word whenever the local CE-bound IWF is in packet loss state.

CE-Bound Decapsulation Behavior The CE-bound IWF is responsible for removing the PSN and VPWS demultiplexing headers, PLE control word, and RTP header from the received packet stream and sending the bit-stream out via the local attachment circuit. A de-jitter buffer MUST be implemented where the PLE packets are stored upon arrival. The size of this buffer SHOULD be locally configurable to allow accommodation of specific PSN PDV expected. The CE-bound IWF SHOULD use the sequence number in the control word to detect lost and misordered packets. It MAY use the sequence number in the RTP header for the same purpose. The CE-bound IWF MAY support reordering of packets received out of order. If the CE-bound IWF does not support reordering, it MUST drop the misordered packets. The payload of a lost or dropped packet MUST be replaced with an equivalent amount of replacement data. The contents of the replacement data MAY be locally configurable. By default, all PLE implementations MUST support generation of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xAA" pattern ensures clock synchronization is maintained and, for 64B/66B code-based services, ensures no invalid sync headers are generated. While sending out the replacement data, the IWF will apply a holdover mechanism to maintain the clock. Whenever the VPWS is not operationally up, the CE-bound NSP function MUST inject the appropriate downstream fault-indication signal. Whenever a VPWS comes up, the CE-bound IWF will enter the intermediate state, will start receiving PLE packets, and will store them in the jitter buffer. The CE-bound NSP function will continue to inject the appropriate downstream fault-indication signal until a preconfigured number of payload s stored in the jitter buffer. After the preconfigured amount of payload is present in the jitter buffer, the CE-bound IWF transitions to the normal operation state, and the content of the jitter buffer is streamed out to the CE in accordance with the required clock. In this state, the CE-bound IWF MUST perform egress clock recovery. Considerations for choosing the preconfigured amount of payload 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
• 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 requirements applicable to the type of attachment circuit, specified in:

• , , and for SDH
• and for SONET
• for synchronous Ethernet
• for OTN

Whenever the L bit is set in the PLE control word of a received PLE packet, the CE-bound NSP function SHOULD inject the appropriate downstream fault-indication signal instead of streaming out the payload. If the CE-bound IWF detects loss of consecutive packets for a preconfigured amount of time (default is 1 millisecond), it enters PLOS state and a corresponding defect is declared. If the CE-bound IWF detects a PLR above a configurable SD threshold for a configurable amount of consecutive 1-second intervals, it enters the DEG state and a corresponding defect is declared. The SD-PLR threshold can be defined as a percentage with the default being 15% or absolute packet count for finer granularity for higher rate interfaces. Possible values for consecutive intervals are 2..10 with the default 7. While the PLOS defect is declared, the CE-bound NSP function MUST inject the appropriate downstream fault-indication signal. If the emulated service does not have an appropriate maintenance signal defined, the CE-bound NSP function MAY disable its transmitter instead. Also, the PSN-bound IWF SHOULD set the R bit in the PLE control word of every packet transmitted. The CE-bound IWF changes from the PLOS to normal state after the preconfigured amount of payload has been received similar to the transition from intermediate to normal state. Whenever the R bit is set in the PLE control word of a received PLE packet, the PLE performance monitoring statistics SHOULD get updated.

PLE Performance Monitoring Attachment circuit performance monitoring SHOULD be provided by the NSP. The performance monitors are service specific, documented in related specifications, and beyond the scope of this document. The PLE IWF SHOULD provide functions to monitor the network performance to be inline with expectations of transport network operators. The near-end performance monitors defined for PLE are as follows:

• ES-PLE : PLE Errored Seconds
• SES-PLE : PLE Severely Errored Seconds
• UAS-PLE : PLE Unavailable Seconds

Each second with at least one packet lost or a PLOS or DEG defect SHALL be counted as an ES-PLE. Each second with a PLR greater than 15% or a PLOS or DEG defect SHALL be counted as an SES-PLE. UAS-PLE SHALL be counted after a configurable number of consecutive SES-PLEs have been observed, and no longer counted after a configurable number of consecutive seconds without an SES-PLE have been observed. The default value for each is 10 seconds. Once unavailability is detected, ES-PLE and SES-PLE counts SHALL be inhibited up to the point where the unavailability was started. Once unavailability is removed, ES-PLE and SES-PLE that occurred along the clearing period SHALL be added to the ES-PLE and SES-PLE counts. A PLE far-end performance monitor provides insight into the CE-bound IWF at the far end of the PSN. The statistics are based on the PLE-RDI indication carried in the PLE control word via the R bit. The PLE VPWS performance monitors are derived from the definitions in accordance with . Performance monitoring data MUST be provided by the management interface and SHOULD be provided by a YANG data model. The YANG data model specification is out of scope for this document.

PLE Fault Management Attachment circuit faults applicable to PLE are detected by the NSP, are service specific, and are documented in . The two PLE faults, PLOS and DEG, are detected by the IWF. Faults MUST be timestamped as they are declared and cleared; fault-related information MUST be provided by the management interface and SHOULD be provided by a YANG data model. The YANG data model specification is out of scope for this document.

QoS and Congestion Control The PSN carrying PLE VPWS may be subject to congestion. Congestion considerations for PWs are described in . PLE VPWS represent inelastic CBR flows that cannot respond to congestion in a TCP-friendly manner (as described in ) and are sensitive to jitter, packet loss, and packets received out of order. The PSN providing connectivity between PE devices of a PLE VPWS has to ensure low jitter and low loss. The exact mechanisms used are beyond the scope of this document and may evolve over time. Possible options, but not exhaustively, are as follows:

• a Diffserv-enabled PSN with a per-domain behavior (see ) supporting Expedited Forwarding (see ),
• traffic-engineered paths through the PSN with bandwidth reservation and admission control applied, or
• capacity over-provisioning.

Security Considerations As PLE is leveraging VPWS as transport mechanism, the security considerations described in are applicable. PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required. The PSN (MPLS or SRv6) is assumed to be trusted and secure. Attackers who manage to send spoofed packets into the PSN could easily disrupt the PLE service. This MUST be prevented by following best practices for the isolation of the PSN. These protections are described in , , , and . PLE PWs share susceptibility to a number of pseudowire-layer attacks and will use whatever mechanisms for confidentiality, integrity, and authentication that are developed for general PWs. These methods are beyond the scope of this document. Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks more difficult. Misconnection detection using the SSRC and/or PT field of the RTP header can increase the resilience to misconfiguration and some types of denial-of-service (DoS) attacks. Randomly chosen expected values decrease the chance of a spoofing attack being successful. 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 leading to either degradation or service disruption. Considerations outlined in are a good reference. Clock synchronization leveraging PTP is sensitive to PDV and vulnerable to various threats and attack vectors. Considerations outlined in should be taken into account.

IANA Considerations

Bit-Stream Next Header Type This document introduces a new value to be used in the next header field of an IPv6 header or any extension header indicating that the payload is an emulated bit-stream. IANA has assigned the following from the "Assigned Internet Protocol Numbers" registry .

Decimal	Keyword	Protocol	IPv6 Extension Header	Reference
147	BIT-EMU	Bit-stream Emulation	Y	RFC 9801

SRv6 Endpoint Behaviors This document introduces three new SRv6 Endpoint behaviors. IANA has assigned identifier values in the "SRv6 Endpoint Behaviors" registry under the "Segment Routing" registry group .

Value	Hex	Endpoint Behavior	Reference
158	0x009E	End.DX1	RFC 9801
159	0x009F	End.DX1 with NEXT-CSID	RFC 9801
160	0x00A0	End.DX1 with REPLACE-CSID	RFC 9801

References Normative References ITU-T ITU-T ITU-T ITU-T ITU-T ITU-T ITU-T ITU-T ITU-T ITU-T Telcordia GR-253 Telcordia GR-499 IANA IANA IEEE In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK] This document describes a profile called "RTP/AVP" for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. This memorandum obsoletes RFC 1890. It is mostly backwards-compatible except for functions removed because two interoperable implementations were not found. The additions to RFC 1890 codify existing practice in the use of payload formats under this profile and include new payload formats defined since RFC 1890 was published. [STANDARDS-TRACK] This document describes an architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Relay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using IP or MPLS. It presents the architectural framework for pseudo wires (PWs), defines terminology, and specifies the various protocol elements and their functions. This memo provides information for the Internet community. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). Segment Routing over IPv6 (SRv6) is the instantiation of Segment Routing (SR) on the IPv6 data plane. This document specifies new flavors for the SRv6 endpoint behaviors defined in RFC 8986, which enable the compression of an SRv6 segment list. Such compression significantly reduces the size of the SRv6 encapsulation needed to steer packets over long segment lists. This document updates RFC 8754 by allowing a Segment List entry in the Segment Routing Header (SRH) to be either an IPv6 address, as specified in RFC 8754, or a REPLACE-CSID container in packed format, as specified in this document. Informative References ATIS ATIS-0900105.09.2013(S2023) Verizon Verizon Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. Work in Progress INCITS INCITS INCITS INCITS INCITS ISO/IEC ITU-T Cisco Systems, Inc. Work in Progress This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK] This document defines and discusses Per-Domain Behaviors in detail and lays out the format and required content for contributions to the Diffserv WG on PDBs and the procedure that will be applied for individual PDB specifications to advance as WG products. This format is specified to expedite working group review of PDB submissions. This memo provides information for the Internet community. This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK] This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP traffic and to the control traffic for RTP, the Real-time Transport Control Protocol (RTCP). [STANDARDS-TRACK] This document defines the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETwork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned to the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It makes references to the generic requirements for PWE3 where applicable and complements them by defining requirements originating from specifics of TDM circuits. This memo provides information for the Internet community. This document analyses the security of the BGP/MPLS IP virtual private network (VPN) architecture that is described in RFC 4364, for the benefit of service providers and VPN users. The analysis shows that BGP/MPLS IP VPN networks can be as secure as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or Frame Relay. This memo provides information for the Internet community. This document describes the preferred design of a Pseudowire Emulation Edge-to-Edge (PWE3) Control Word to be used over an MPLS packet switched network, and the Pseudowire Associated Channel Header. The design of these fields is chosen so that an MPLS Label Switching Router performing MPLS payload inspection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK] This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK] This document provides a framework for Layer 2 Provider Provisioned Virtual Private Networks (L2VPNs). This framework is intended to aid in standardizing protocols and mechanisms to support interoperable L2VPNs. This memo provides information for the Internet community. This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK] This document describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RSVP-TE without requiring a multicast routing protocol in the Service Provider core. Protocol elements and procedures for this solution are described. There can be various applications for P2MP TE LSPs such as IP multicast. Specification of how such applications will use a P2MP TE LSP is outside the scope of this document. [STANDARDS-TRACK] This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchronized Optical Network (SONET) circuit emulation service across an MPLS network. This document describes the so-called "draft-martini" protocol, which has since been superseded by the Pseudowire Emulation Edge to Edge Working Group specifications described in RFC 4447 and related documents. This memo defines a Historic Document for the Internet community. The architecture for Multiprotocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths. [STANDARDS-TRACK] This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community. This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes. The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. As time and frequency distribution protocols are becoming increasingly common and widely deployed, concern about their exposure to various security threats is increasing. This document defines a set of security requirements for time protocols, focusing on the Precision Time Protocol (PTP) and the Network Time Protocol (NTP). This document also discusses the security impacts of time protocol practices, the performance implications of external security practices on time protocols, and the dependencies between other security services and time synchronization. Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents. This document is a rewrite of RFC 4447 for publication as an Internet Standard. This document describes how Ethernet VPN (EVPN) can be used to support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomplishes the following for VPWS: provides Single-Active as well as All-Active multihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. A DetNet (deterministic network) provides specific performance guarantees to its data flows, such as extremely low data loss rates and bounded latency (including bounded latency variation, i.e., "jitter"). As a result, securing a DetNet requires that in addition to the best practice security measures taken for any mission-critical network, additional security measures may be needed to secure the intended operation of these novel service properties. This document addresses DetNet-specific security considerations from the perspectives of both the DetNet system-level designer and component designer. System considerations include a taxonomy of relevant threats and attacks, and associations of threats versus use cases and service properties. Component-level considerations include ingress filtering and packet arrival-time violation detection. This document also addresses security considerations specific to the IP and MPLS data plane technologies, thereby complementing the Security Considerations sections of those documents. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. INCITS

Acknowledgements The authors would like to thank , , , , , , and for their early contributions, review, comments, and suggestions. Special thank you to:

• and for giving the authors new-to-the-IETF guidance on how to get started
• for being our shepherd
• , , , , and for their reviews and suggestions during Last Call
• and for their guidance through the process

Contributors 1&1 Versatel

andreas.burk@magenta.de

AMD

faisal.dada@amd.com

Ciena Corporation

gsmalleg@ciena.com

Aimvalley

erik.vanveelen@aimvalley.com

Cisco Systems, Inc.

ldellach@cisco.com

Cisco Systems, Inc.

naikumar@cisco.com

Blue Fern Consulting

Carlos@Bluefern.consulting

Authors' Addresses Verizon

steven.gringeri@verizon.com

Verizon

jeremy.whittaker@verizon.com

Deutsche Telekom

N.Leymann@telekom.de

Cisco Systems, Inc.

cschmutz@cisco.com

Ciena Corporation

cbrown@ciena.com