rfc9801.original.xml   rfc9801.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.2. -ietf-pals-ple-15" number="9801" category="std" consensus="true" submissionType=
3) --> "IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" updates="" o
<?rfc comments="yes"?> bsoletes="" xml:lang="en">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-pals-ple-15" category="std" consensus="true" submissionType="IETF" tocIncl
ude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.27.0 -->
<front> <front>
<title abbrev="PLE">Private Line Emulation over Packet Switched Networks</ti
tle> <title abbrev="PLE over PSNs">Private Line Emulation over Packet Switched Ne
<seriesInfo name="Internet-Draft" value="draft-ietf-pals-ple-15"/> tworks</title>
<seriesInfo name="RFC" value="9801"/>
<author initials="S." surname="Gringeri" fullname="Steven Gringeri"> <author initials="S." surname="Gringeri" fullname="Steven Gringeri">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<email>steven.gringeri@verizon.com</email> <email>steven.gringeri@verizon.com</email>
</address> </address>
</author> </author>
<author initials="J." surname="Whittaker" fullname="Jeremy Whittaker"> <author initials="J." surname="Whittaker" fullname="Jeremy Whittaker">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<email>jeremy.whittaker@verizon.com</email> <email>jeremy.whittaker@verizon.com</email>
skipping to change at line 46 skipping to change at line 45
<address> <address>
<email>cschmutz@cisco.com</email> <email>cschmutz@cisco.com</email>
</address> </address>
</author> </author>
<author initials="C." surname="Brown" fullname="Chris Brown"> <author initials="C." surname="Brown" fullname="Chris Brown">
<organization>Ciena Corporation</organization> <organization>Ciena Corporation</organization>
<address> <address>
<email>cbrown@ciena.com</email> <email>cbrown@ciena.com</email>
</address> </address>
</author> </author>
<date year="2025" month="February" day="12"/> <date year="2025" month="July"/>
<abstract> <area>RTG</area>
<?line 308?> <workgroup>pals</workgroup>
<t>This document expands the applicability of virtual private wire services (VPW <abstract>
S) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provi <t>This document expands the applicability of Virtual Private Wire
des pseudowire transport with complete signal transparency over packet switched Service (VPWS) bit-stream payloads beyond Time Division Multiplexing
networks (PSN).</t> (TDM) signals and provides pseudowire transport with complete signal
transparency over Packet Switched Networks (PSNs).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 314?> <?line 314?>
<section anchor="introduction-and-motivation"> <section anchor="introduction-and-motivation">
<name>Introduction and Motivation</name> <name>Introduction and Motivation</name>
<t>This document describes a method called Private Line Emulation (PLE) fo r 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 <xref target="RFC4553"/>.</t> <t>This document describes a method called Private Line Emulation (PLE) fo r 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 <xref target="RFC4553"/>.</t>
<t>This emulation suits applications, where carrying Protocol Data Units ( PDUs) as defined in <xref target="RFC4906"/> or <xref target="RFC4448"/> is not enough, physical layer signal transparency is required and data or framing struc ture interpretation of the Provider Edge (PE) would be counterproductive.</t> <t>This emulation suits applications, where carrying Protocol Data Units ( PDUs) as defined in <xref target="RFC4906"/> or <xref target="RFC4448"/> is not enough, physical layer signal transparency is required and data or framing struc ture interpretation of the Provider Edge (PE) would be counterproductive.</t>
<t>One example of such case is two Ethernet connected Customer Edge (CE) d evices and the need for Synchronous Ethernet <xref target="G.8261"/> operation b etween them without the intermediate PE devices interfering or addressing concer ns about Ethernet control protocol transparency for PDU based carrier Ethernet s ervices, beyond the behavior definitions of Metro Ethernet Forum (MEF) specifica tions.</t> <t>One example of such case is two Ethernet-connected Customer Edge (CE) d evices and the need for Synchronous Ethernet operation (see <xref target="G.8261 "/>) between them without the intermediate PE devices interfering or addressing concerns about Ethernet control protocol transparency for PDU-based carrier Ethe rnet services, beyond the behavior definitions of MEF Forum (MEF) specifications .</t>
<t>Another example would be a Storage Area Networking (SAN) extension betw een two data centers. Operating at a bit-stream level allows for a connection be tween Fibre Channel switches without interfering with any of the Fibre Channel p rotocol mechanisms defined by <xref target="T11"/>.</t> <t>Another example would be a Storage Area Networking (SAN) extension betw een two data centers. Operating at a bit-stream level allows for a connection be tween Fibre Channel switches without interfering with any of the Fibre Channel p rotocol mechanisms defined by <xref target="T11"/>.</t>
<t>Also, SONET/SDH add/drop multiplexers or cross-connects can be intercon <t>Also, SONET/SDH (Synchronous Optical Network (SONET) / Synchronous Digi
nected without interfering with the multiplexing structures and networks mechani tal Hierarchy (SDH)) add/drop multiplexers or cross-connects can be interconnect
sms. This is a key distinction to Circuit Emulation over Packet (CEP) defined in ed without interfering with the multiplexing structures and networks mechanisms.
<xref target="RFC4842"/> where demultiplexing and multiplexing is desired in or This is a key distinction to Circuit Emulation over Packet (CEP) defined in <xr
der to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributar ef target="RFC4842"/> where multiplexing and demultiplexing is desired in order
y (VT) or SDH Virtual Container (VC). Said in another way, PLE does provide an i to operate per SONET Synchronous Payload Envelope (SPE) and Virtual Tributary (V
ndependent layer network underneath the SONET/SDH layer network, whereas CEP doe T) or SDH Virtual Container (VC). In other words, PLE provides an independent la
s operate at the same level and peer with the SONET/SDH layer network.</t> yer network underneath the SONET/SDH layer network, whereas CEP operates at the
<t>The mechanisms described in this document follow principles similar to same level and peer with the SONET/SDH layer network.</t>
Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) defined <t>The mechanisms described in this document follow principles similar to
in <xref target="RFC4553"/>. The applicability is expanded beyond the narrow set Structure-Agnostic TDM over Packet (SAToP) (defined in <xref target="RFC4553"/>)
of Plesiochronous Digital Hierarchy (PDH) interfaces (T1, E1, T3 and E3) to all . The applicability is expanded beyond the narrow set of Plesiochronous Digital
ow the transport of signals from many different technologies such as Ethernet, F Hierarchy (PDH) interfaces (T1, E1, T3, and E3) to allow the transport of signal
ibre Channel, SONET/SDH <xref target="GR253"/>/<xref target="G.707"/> and OTN <x s from many different technologies such as Ethernet, Fibre Channel, SONET/SDH (<
ref target="G.709"/> at gigabit speeds. The signals are treated as bit-stream pa xref target="GR253"/> / <xref target="G.707"/>), and Optical Transport Network (
yload which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) archite OTN) <xref target="G.709"/> at gigabit speeds. The signals are treated as bit-st
cture in <xref target="RFC3985"/> sections 3.3.3 and 3.3.4.</t> ream payload, which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3)
architecture in Sections <xref target="RFC3985" sectionFormat="bare" section="3
.3.3"/> and <xref target="RFC3985" sectionFormat="bare" section="3.3.4"/> of <xr
ef target="RFC3985"/>.</t>
</section> </section>
<section anchor="requirements-notation"> <section anchor="requirements-notation">
<name>Requirements Notation</name> <name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119 "/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, a s shown here.</t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14> SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bc p14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14> " in this document are to be interpreted as described in BCP 14 <xref target="RF C2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capita ls, as shown here.</t>
</section> </section>
<section anchor="terminology-and-reference-model"> <section anchor="terminology-and-reference-model">
<name>Terminology and Reference Model</name> <name>Terminology and Reference Models</name>
<section anchor="terminology">
<name>Terminology</name> <section anchor="terminology">
<ul spacing="normal">
<li> <name>Abbreviations</name>
<t>ACH - Associated Channel Header <xref target="RFC7212"/></t> <dl spacing="normal" newline="false">
</li> <dt>ACH:</dt><dd>Associated Channel Header <xref target="RFC7212"/><
<li> /dd>
<t>AIS - Alarm Indication Signal</t> <dt>AIS:</dt><dd>Alarm Indication Signal</dd>
</li> <dt>AIS-L:</dt><dd>Line AIS</dd>
<li> <dt>MS-AIS:</dt><dd>Multiplex Section AIS</dd>
<t>AIS-L - Line AIS</t> <dt>BITS:</dt><dd>Building Integrated Timing Supply <xref target="AT
</li> IS-0900105.09.2013"/></dd>
<li> <dt>CBR:</dt><dd>Constant Bit Rate</dd>
<t>AS - Autonomous System</t> <dt>CE:</dt><dd>Customer Edge</dd>
</li> <dt>CEP:</dt><dd>Circuit Emulation over Packet <xref target="RFC4842
<li> "/></dd>
<t>ASBR - Autonomous System Border Router</t> <dt>CSRC:</dt><dd>Contributing Source <xref target="RFC3550"/></dd>
</li> <dt>DEG:</dt><dd>Degradation</dd>
<li> <dt>ES:</dt><dd>Errored Second</dd>
<t>MS-AIS - Multiplex Section AIS</t> <dt>FEC:</dt><dd>Forward Error Correction</dd>
</li> <dt>ICMP:</dt><dd>Internet Control Message Protocol <xref target="RF
<li> C4443"/></dd>
<t>BITS - Building Integrated Timing Supply <xref target="ATIS-09001 <dt>IEEE:</dt><dd>Institute of Electrical and Electronics Engineers<
05.09.2013"/></t> /dd>
</li> <dt>INCITS:</dt><dd>INternational Committee for Information Technolo
<li> gy Standards</dd>
<t>CBR - Constant Bit Rate</t> <dt>IWF:</dt><dd>Interworking Function</dd>
</li> <dt>LDP:</dt><dd>Label Distribution Protocol <xref target="RFC5036"/
<li> >, <xref target="RFC8077"/></dd>
<t>CE - Customer Edge</t> <dt>LF:</dt><dd>Local Fault</dd>
</li> <dt>LOF:</dt><dd>Loss Of Frame</dd>
<li> <dt>LOM:</dt><dd>Loss Of Multiframe</dd>
<t>CEP - Circuit Emulation over Packet <xref target="RFC4842"/></t> <dt>LOS:</dt><dd>Loss Of Signal</dd>
</li> <dt>LPI:</dt><dd>Low Power Idle</dd>
<li> <dt>LSP:</dt><dd>Label Switched Path</dd>
<t>CSRC - Contributing SouRCe <xref target="RFC3550"/></t> <dt>MEF:</dt><dd>MEF Forum</dd>
</li> <dt>MPLS:</dt><dd>Multiprotocol Label Switching <xref target="RFC303
<li> 1"/></dd>
<t>DEG - Degradation</t> <dt>NOS:</dt><dd>Not Operational</dd>
</li> <dt>NSP:</dt><dd>Native Service Processing <xref target="RFC3985"/><
<li> /dd>
<t>ES - Errored Second</t> <dt>ODUk:</dt><dd>Optical Data Unit k</dd>
</li> <dt>OOF:</dt><dd>Out Of Frame</dd>
<li> <dt>OTN:</dt><dd>Optical Transport Network</dd>
<t>FEC - Forward Error Correction</t> <dt>OTUk:</dt><dd>Optical Transport Unit k</dd>
</li> <dt>PCS:</dt><dd>Physical Coding Sublayer</dd>
<li> <dt>PDV:</dt><dd>Packet Delay Variation</dd>
<t>ICMP - Internet Control Message Protocol <xref target="RFC4443"/> <dt>PE:</dt><dd>Provider Edge</dd>
</t> <dt>PLE:</dt><dd>Private Line Emulation</dd>
</li> <dt>PLOS:</dt><dd>Packet Loss Of Signal</dd>
<li> <dt>PLR:</dt><dd>Packet Loss Rate</dd>
<t>IEEE - Institute of Electrical and Electronics Engineers</t> <dt>PMA:</dt><dd>Physical Medium Attachment</dd>
</li> <dt>PMD:</dt><dd>Physical Medium Dependent</dd>
<li> <dt>PSN:</dt><dd>Packet Switched Network</dd>
<t>INCITS - InterNational Committee for Information Technology Stand <dt>PTP:</dt><dd>Precision Time Protocol</dd>
ards</t> <dt>PW:</dt><dd>Pseudowire <xref target="RFC4664"/></dd>
</li> <dt>PWE3:</dt><dd>Pseudo Wire Emulation Edge-to-Edge <xref target="R
<li> FC3985"/></dd>
<t>IWF - InterWorking Function</t> <dt>RDI:</dt><dd>Remote Defect Indication</dd>
</li> <dt>RSVP-TE:</dt><dd>Resource Reservation Protocol Traffic Engineeri
<li> ng <xref target="RFC4875"/></dd>
<t>LDP - Label Distribution Protocol <xref target="RFC5036"/>, <xref <dt>RTCP:</dt><dd>RTP Control Protocol <xref target="RFC3550"/></dd>
target="RFC8077"/></t> <dt>RTP:</dt><dd>Real-time Transport Protocol <xref target="RFC3550"
</li> /></dd>
<li> <dt>SD:</dt><dd>Signal Degrade</dd>
<t>LF - Local Fault</t> <dt>SES:</dt><dd>Severely Errored Seconds</dd>
</li> <dt>SDH:</dt><dd>Synchronous Digital Hierarchy</dd>
<li> <dt>SID:</dt><dd>Segment Identifier <xref target="RFC8402"/></dd>
<t>LOF - Loss Of Frame</t> <dt>SR:</dt><dd>Segment Routing <xref target="RFC8402"/></dd>
</li> <dt>SRH:</dt><dd>Segment Routing Header <xref target="RFC8754"/></dd
<li> >
<t>LOM - Loss Of Multiframe</t> <dt>SRTP:</dt><dd>Secure Real-time Transport Protocol <xref target="
</li> RFC3711"/></dd>
<li> <dt>SRv6:</dt><dd>Segment Routing over IPv6 <xref target="RFC8986"/>
<t>LOS - Loss Of Signal</t> </dd>
</li> <dt>SSRC:</dt><dd>Synchronization Source <xref target="RFC3550"/></d
<li> d>
<t>LPI - Low Power Idle</t> <dt>SONET:</dt><dd>Synchronous Optical Network</dd>
</li> <dt>TCP:</dt><dd>Transmission Control Protocol <xref target="RFC9293
<li> "/></dd>
<t>LSP - Label Switched Path</t> <dt>TDM:</dt><dd>Time Division Multiplexing</dd>
</li> <dt>TTS:</dt><dd>Transmitter Training Signal</dd>
<li> <dt>UAS:</dt><dd>Unavailable Seconds</dd>
<t>MEF - Metro Ethernet Forum</t> <dt>VPWS:</dt><dd>Virtual Private Wire Service <xref target="RFC3985
</li> "/></dd>
<li> </dl>
<t>MPLS - Multi Protocol Label Switching <xref target="RFC3031"/></t <aside>
> <t>Note: The term Interworking Function (IWF) is used to describe the fu
</li> nctional block that encapsulates bit-streams into PLE packets and in the reverse
<li> direction decapsulates PLE packets and reconstructs bit-streams.</t></aside>
<t>NOS - Not Operational</t>
</li>
<li>
<t>NSP - Native Service Processor <xref target="RFC3985"/></t>
</li>
<li>
<t>ODUk - Optical Data Unit k</t>
</li>
<li>
<t>OTN - Optical Transport Network</t>
</li>
<li>
<t>OTUk - Optical Transport Unit k</t>
</li>
<li>
<t>PCS - Physical Coding Sublayer</t>
</li>
<li>
<t>PDH - Plesiochronous Digital Hierarchy</t>
</li>
<li>
<t>PDV - Packet Delay Variation</t>
</li>
<li>
<t>PE - Provider Edge</t>
</li>
<li>
<t>PLE - Private Line Emulation</t>
</li>
<li>
<t>PLOS - Packet Loss Of Signal</t>
</li>
<li>
<t>PLR - Packet Loss Ratio</t>
</li>
<li>
<t>PMA - Physical Medium Attachment</t>
</li>
<li>
<t>PMD - Physical Medium Dependent</t>
</li>
<li>
<t>PSN - Packet Switched Network</t>
</li>
<li>
<t>PTP - Precision Time Protocol</t>
</li>
<li>
<t>PW - Pseudowire <xref target="RFC3985"/></t>
</li>
<li>
<t>PWE3 - Pseudo Wire Emulation Edge-to-Edge <xref target="RFC3985"/
></t>
</li>
<li>
<t>P2P - Point-to-Point</t>
</li>
<li>
<t>QOS - Quality Of Service</t>
</li>
<li>
<t>RDI - Remote Defect Indication</t>
</li>
<li>
<t>RSVP-TE - Resource Reservation Protocol Traffic Engineering <xref
target="RFC4875"/></t>
</li>
<li>
<t>RTCP - RTP Control Protocol <xref target="RFC3550"/></t>
</li>
<li>
<t>RTP - Realtime Transport Protocol <xref target="RFC3550"/></t>
</li>
<li>
<t>SAN - Storage Area Network</t>
</li>
<li>
<t>SAToP - Structure-Agnostic Time Division Multiplexing (TDM) over
Packet <xref target="RFC4553"/></t>
</li>
<li>
<t>SD - Signal Degrade</t>
</li>
<li>
<t>SES - Severely Errored Second</t>
</li>
<li>
<t>SDH - Synchronous Digital Hierarchy</t>
</li>
<li>
<t>SID - Segment Identifier <xref target="RFC8402"/></t>
</li>
<li>
<t>SPE - Synchronous Payload Envelope</t>
</li>
<li>
<t>SR - Segment Routing <xref target="RFC8402"/></t>
</li>
<li>
<t>SRH - Segment Routing Header <xref target="RFC8754"/></t>
</li>
<li>
<t>SRTP - Secure Realtime Transport Protocol <xref target="RFC3711"/
></t>
</li>
<li>
<t>SRv6 - Segment Routing over IPv6 Dataplane <xref target="RFC8986"
/></t>
</li>
<li>
<t>SSRC - Synchronization SouRCe <xref target="RFC3550"/></t>
</li>
<li>
<t>SONET - Synchronous Optical Network</t>
</li>
<li>
<t>TCP - Transmission Control Protocol <xref target="RFC9293"/></t>
</li>
<li>
<t>TDM - Time Division Multiplexing</t>
</li>
<li>
<t>TTS - Transmitter Training Signal</t>
</li>
<li>
<t>UAS - Unavailable Second</t>
</li>
<li>
<t>VPWS - Virtual Private Wire Service <xref target="RFC3985"/></t>
</li>
<li>
<t>VC - Virtual Circuit</t>
</li>
<li>
<t>VT - Virtual Tributary</t>
</li>
</ul>
<t>The term Interworking Function (IWF) is used to describe the function
al block that encapsulates bit streams into PLE packets and in the reverse direc
tion decapsulates PLE packets and reconstructs bit streams.</t>
</section> </section>
<section anchor="reference-models"> <section anchor="reference-models">
<name>Reference Models</name> <name>Reference Models</name>
<t>The reference model for PLE is illustrated in <xref target="ref_model "/> and is inline with the reference model defined in <xref section="4.1" sectio nFormat="of" target="RFC3985"/>. PLE does rely on PWE3 pre-processing, in partic ular the concept of a Native Service Processing (NSP) function defined in <xref section="4.2.2" sectionFormat="of" target="RFC3985"/>.</t> <t>The reference model for PLE is illustrated in <xref target="ref_model "/> and is inline with the reference model defined in <xref section="4.1" sectio nFormat="of" target="RFC3985"/>. PLE relies on PWE3 preprocessing, in particular the concept of an NSP function defined in <xref section="4.2.2" sectionFormat=" of" target="RFC3985"/>.</t>
<figure anchor="ref_model"> <figure anchor="ref_model">
<name>PLE Reference Model</name> <name>PLE Reference Model</name>
<artwork><![CDATA[ <artwork><![CDATA[
|<--- p2p L2VPN service -->| |<--- p2p L2VPN service -->|
| | | |
| |<-PSN tunnel->| | | |<-PSN tunnel->| |
v v v v v v v v
+---------+ +---------+ +---------+ +---------+
| PE1 |==============| PE2 | | PE1 |==============| PE2 |
+---+-----+ +-----+---+ +---+-----+ +-----+---+
skipping to change at line 315 skipping to change at line 171
+-----+ ^ | 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
]]></artwork> ]]></artwork>
</figure> </figure>
<t>PLE embraces the minimum intervention principle outlined in <xref sec
tion="3.3.5" sectionFormat="of" target="RFC3985"/> whereas the data is flowing t <t>PLE embraces the minimum intervention principle outlined in <xref sec
hrough the PLE encapsulation layer as received without modifications.</t> tion="3.3.5" sectionFormat="of" target="RFC3985"/>, which means the data is flow
<t>For some service types the NSP function is responsible for performing ing through the PLE encapsulation layer as received without modifications.</t>
operations on the native data received from the CE. Examples are terminating Fo <t>For some service types, the NSP function is responsible for performin
rward Error Correction (FEC), terminating the OTUk layer for OTN or dealing with g operations on the data received from the CE. Examples are terminating FEC, ter
multi-lane processing. After the NSP, the IWF is generating the payload of the minating the OTUk layer for OTN, or dealing with multi-lane processing. After th
VPWS which is carried via a PSN tunnel.</t> e NSP, the IWF is generating the payload of the VPWS, which is carried via a PSN
<t>To allow the clock of the transported signal to be carried across the tunnel.</t>
PLE domain in a transparent way the relative network synchronization reference <t>To allow the clock of the transported signal to be carried across the
model and deployment scenario outlined in <xref section="4.3.2" sectionFormat="o PLE domain in a transparent way, the relative network synchronization reference
f" target="RFC4197"/> are applicable and are shown in <xref target="diff_clock"/ model and deployment scenario outlined in <xref section="4.3.2" sectionFormat="
>.</t> of" target="RFC4197"/> are applicable and are shown in <xref target="diff_clock"
/>.</t>
<figure anchor="diff_clock"> <figure anchor="diff_clock">
<name>Relative Network Scenario Timing</name> <name>Relative Network Scenario Timing</name>
<artwork><![CDATA[ <artwork><![CDATA[
J J
| G | G
| | | |
| +-----+ +-----+ v | +-----+ +-----+ v
+-----+ v |- - -|=================|- - -| +-----+ +-----+ v |- - -|=================|- - -| +-----+
| |<---------|.............................|<---------| | | |<---------|.............................|<---------| |
| CE1 | | PE1 | VPWS | PE2 | | CE2 | | CE1 | | PE1 | VPWS | PE2 | | CE2 |
skipping to change at line 338 skipping to change at line 195
| |--------->|.............................|--------->| | | |--------->|.............................|--------->| |
+-----+ |- - -|=================|- - -| ^ +-----+ +-----+ |- - -|=================|- - -| ^ +-----+
^ +-----+ +-----+ | ^ +-----+ +-----+ |
| ^ C D ^ | | ^ C D ^ |
A | | | A | | |
+-----------+-----------+ E +-----------+-----------+ E
| |
+-+ +-+
|I| |I|
+-+ +-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The local oscillators C of PE1 and D of PE2 are locked to a common cl ock I.</t> <t>The local oscillators C of PE1 and D of PE2 are locked to a common cl ock I.</t>
<t>The attachment circuit clock E is generated by PE2 via a differential <t>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 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 transfer difference between clock A and clock C (locked to I) <bcp14>MUST</bcp14> be exp
red from PE1 to PE2 using the timestamp inside the RTP header.</t> licitly transferred from PE1 to PE2 using the timestamp inside the RTP header.</
<t>For the reverse direction PE1 does generate the attachment circuit cl t>
ock J and the clock difference between G and D (locked to I) transferred from PE
2 to PE1.</t> <t>For the reverse direction, PE1 generates the attachment circuit clock
<t>The method used to lock clocks C and D to the common clock I is out o J and the clock difference between G and D (locked to I) is transferred from PE
f scope of this document, but there are already several well-established concept 2 to PE1.</t>
s for achieving clock synchronization, commonly also referred to as frequency sy <t>The method used to lock clocks C and D to the common clock I is out o
nchronization, available.</t> f scope of this document; however, there are already several well-established co
<t>While using external timing inputs (aka BITS <xref target="ATIS-09001 ncepts for achieving clock synchronization (commonly also referred to as "freque
05.09.2013"/>) or synchronous Ethernet as defined in <xref target="G.8261"/> the ncy synchronization") available.</t>
characteristics and limits defined in <xref target="G.8262"/> have to be consid <t>While using external timing inputs (aka BITS <xref target="ATIS-09001
ered.</t> 05.09.2013"/>) or synchronous Ethernet (as defined in <xref target="G.8261"/>),
<t>While relying on precision time protocol (PTP) as defined in <xref ta the characteristics and limits defined in <xref target="G.8262"/> have to be con
rget="G.8265.1"/>, the network limits defined in <xref target="G.8261.1"/> have sidered.</t>
to be considered.</t> <t>While relying on PTP (as defined in <xref target="G.8265.1"/>), the n
etwork limits defined in <xref target="G.8261.1"/> have to be considered.</t>
</section> </section>
</section> </section>
<section anchor="emulated-services"> <section anchor="emulated-services">
<name>Emulated Services</name> <name>Emulated Services</name>
<t>This specification describes the emulation of services from a wide rang e of technologies, such as TDM, Ethernet, Fibre Channel, or OTN, as bit streams or structured bit streams, as defined in Section 3.3.3 and Section 3.3.4 of <xre f target="RFC3985"/>.</t> <t>This specification describes the emulation of services from a wide rang e of technologies, such as TDM, Ethernet, Fibre Channel, or OTN, as bit-streams or structured bit-streams, as defined in Sections <xref target="RFC3985" section Format="bare" section="3.3.3"/> and <xref target="RFC3985" sectionFormat="bare" section="3.3.4"/> of <xref target="RFC3985"/>.</t>
<section anchor="generic-ple-service"> <section anchor="generic-ple-service">
<name>Generic PLE Service</name> <name>Generic PLE Service</name>
<t>The generic PLE service is an example of the bit stream defined in <x <t>The generic PLE service is an example of the bit-stream defined in <x
ref section="3.3.3" sectionFormat="of" target="RFC3985"/>.</t> ref section="3.3.3" sectionFormat="of" target="RFC3985"/>.</t>
<t>Under the assumption that the CE-bound IWF is not responsible for any <t>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 g service-specific operation, a bit-stream of any rate can be carried using the g
eneric PLE payload.</t> eneric PLE payload.</t>
<t>There is no NSP function present for this service.</t> <t>There is no NSP function present for this service.</t>
</section> </section>
<section anchor="ethernet-services"> <section anchor="ethernet-services">
<name>Ethernet services</name> <name>Ethernet Services</name>
<t>Ethernet services are special cases of the structured bit stream defi <t>Ethernet services are special cases of the structured bit-stream defi
ned in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t> ned in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
<t>IEEE has defined several layers for Ethernet in <xref target="IEEE802 <t>The IEEE has defined several layers for Ethernet in <xref target="IEE
.3"/>. Emulation is operating at the physical (PHY) layer, more precisely at the E802.3"/>. Emulation is operating at the physical (PHY) layer, more precisely at
Physical Coding Sublayer (PCS).</t> the PCS.</t>
<t>Over time many different Ethernet interface types have been specified <t>Over time, many different Ethernet interface types have been specifie
in <xref target="IEEE802.3"/> with a varying set of characteristics such as opt d in <xref target="IEEE802.3"/> with a varying set of characteristics, such as o
ional vs mandatory FEC and single-lane vs multi-lane transmission.</t> ptional versus mandatory FEC and single-lane versus multi-lane transmission.</t>
<t>Ethernet interface types with backplane physical media dependent (PMD <t>Ethernet interface types with backplane PMD variants and Ethernet int
) variants and Ethernet interface types mandating auto-negotiation (except 1000B erface types mandating auto-negotiation (except 1000Base-X) are out of scope for
ase-X) are out of scope for this document.</t> this document.</t>
<t>All Ethernet services are leveraging the basic PLE payload and interf <t>All Ethernet services are leveraging the basic PLE payload and interf
ace specific mechanisms are confined to the respective service specific NSP func ace-specific mechanisms are confined to the respective service specific NSP func
tions.</t> tions.</t>
<section anchor="base-x"> <section anchor="base-x">
<name>1000BASE-X</name> <name>1000BASE-X</name>
<t>The PCS layer of 1000BASE-X defined in section 36 of <xref target=" <t>The PCS layer of 1000BASE-X (defined in Section 36 of <xref target=
IEEE802.3"/> is based on 8B/10B code.</t> "IEEE802.3"/>) is based on 8B/10B code.</t>
<t>The PSN-bound NSP function does not modify the received data and is <t>The PSN-bound NSP function does not modify the received data and is
transparent to auto-negotiation but is responsible to detect 1000BASE-X specifi transparent to auto-negotiation; however, it is responsible for detecting attac
c attachment circuit faults such as LOS and sync loss.</t> hment circuit faults specific to 1000BASE-X such as LOS and sync loss.</t>
<t>When the CE-bound IWF is in PLOS state or when PLE packets are rece <t>When the CE-bound IWF is in PLOS state or when PLE packets are rece
ived with the L-bit being set, the CE-bound NSP function MAY disable its transmi ived with the L bit set, the CE-bound NSP function <bcp14>MAY</bcp14> disable it
tter as no appropriate maintenance signal was defined for 1000BASE-X by IEEE.</t s transmitter as no appropriate maintenance signal was defined for 1000BASE-X by
> the IEEE.</t>
</section> </section>
<section anchor="gbase-r-and-25gbase-r"> <section anchor="gbase-r-and-25gbase-r">
<name>10GBASE-R and 25GBASE-R</name> <name>10GBASE-R and 25GBASE-R</name>
<t>The PCS layers of 10GBASE-R defined in section 49 and 25GBASE-R def <t>The PCS layers of 10GBASE-R (defined in Section 49 and 25GBASE-R de
ined in section 107 of <xref target="IEEE802.3"/> are based on a 64B/66B code.</ fined in Section 107 of <xref target="IEEE802.3"/>) are based on a 64B/66B code.
t> </t>
<t><xref target="IEEE802.3"/> sections 74 and 108 do define an optiona <t>Sections 74 and 108 of <xref target="IEEE802.3"/> define an optiona
l FEC layer, if present the PSN-bound NSP function MUST terminate the FEC and th l FEC layer; if present, the PSN-bound NSP function <bcp14>MUST</bcp14> terminat
e CE-bound NSP function MUST generate the FEC.</t> e the FEC and the CE-bound NSP function <bcp14>MUST</bcp14> generate the FEC.</t
<t>The PSN-bound NSP function is also responsible to detect 10GBASE-R >
and 25GBASE-R specific attachment circuit faults such as LOS and sync loss.</t> <t>The PSN-bound NSP function is also responsible for detecting attach
<t>The PSN-bound IWF is mapping the scrambled 64B/66B code stream into ment circuit faults specific to 10GBASE-R and 25GBASE-R such as LOS and sync los
the basic PLE payload.</t> s.</t>
<t>The CE-bound NSP function MUST perform</t> <t>The PSN-bound IWF maps the scrambled 64B/66B code stream into the b
asic PLE payload.</t>
<t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>PCS code sync (section 49.2.9 of <xref target="IEEE802.3"/>)</t > <t>PCS code sync (Section 49.2.9 of <xref target="IEEE802.3"/>) an d</t>
</li> </li>
<li> <li>
<t>descrambling (section 49.2.10 of <xref target="IEEE802.3"/>)</t > <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t >
</li> </li>
</ul> </ul>
<t>in order to properly</t> <t>in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transform invalid 66B code blocks into proper error control cha racters /E/ (section 49.2.4.11 of <xref target="IEEE802.3"/>)</t> <t>transform invalid 66B code blocks into proper error control cha racters /E/ (Section 49.2.4.11 of <xref target="IEEE802.3"/>) and</t>
</li> </li>
<li> <li>
<t>insert Local Fault (LF) ordered sets (section 46.3.4 of <xref t arget="IEEE802.3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</t> <t>insert LF ordered sets (Section 46.3.4 of <xref target="IEEE802 .3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received w ith the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid 66B code blocks typically are a consequence of the CE <aside>
-bound IWF inserting replacement data in case of lost PLE packets, or if the far <t>Note: Invalid 66B code blocks typically are a consequence of the CE
-end PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC -bound IWF inserting replacement data in case of lost PLE packets or the far-end
errors.</t> PSN-bound NSP function setting sync headers to 11 due to uncorrectable FEC erro
<t>Before sending the bit stream to the CE, the CE-bound NSP function rs.</t></aside>
MUST also scramble the 64B/66B code stream (section 49.2.6 <xref target="IEEE802 <t>Before sending the bit-stream to the CE, the CE-bound NSP function
.3"/>).</t> <bcp14>MUST</bcp14> also scramble the 64B/66B code stream (Section 49.2.6 <xref
target="IEEE802.3"/>).</t>
</section> </section>
<section anchor="gbase-r-50gbase-r-and-100gbase-r"> <section anchor="gbase-r-50gbase-r-and-100gbase-r">
<name>40GBASE-R, 50GBASE-R and 100GBASE-R</name> <name>40GBASE-R, 50GBASE-R, and 100GBASE-R</name>
<t>The PCS layers of 40GBASE-R and 100GBASE-R defined in section 82 an <t>The PCS layers of 40GBASE-R and 100GBASE-R (defined in Section 82 o
d of 50GBASE-R defined in section 133 of <xref target="IEEE802.3"/> are based on f <xref target="IEEE802.3"/>) and of 50GBASE-R (defined in Section 133 of <xref
a 64B/66B code transmitted over multiple lanes.</t> target="IEEE802.3"/>) are based on a 64B/66B code transmitted over multiple lan
<t><xref target="IEEE802.3"/> sections 74 and 91 do define an optional es.</t>
FEC layer, if present the PSN-bound NSP function MUST terminate the FEC and the <t>Sections 74 and 91 of <xref target="IEEE802.3"/> define an optional
CE-bound NSP function MUST generate the FEC.</t> FEC layer; if present, the PSN-bound NSP function <bcp14>MUST</bcp14> terminate
<t>To gain access to the scrambled 64B/66B code stream the PSN-bound N the FEC and the CE-bound NSP function <bcp14>MUST</bcp14> generate the FEC.</t>
SP further MUST perform</t> <t>To gain access to the scrambled 64B/66B code stream, the PSN-bound
NSP further <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>block synchronization (section 82.2.12 of <xref target="IEEE802 .3"/>)</t> <t>block synchronization (Section 82.2.12 of <xref target="IEEE802 .3"/>),</t>
</li> </li>
<li> <li>
<t>PCS lane de-skew (section 82.2.13 of <xref target="IEEE802.3"/> )</t> <t>PCS lane de-skew (Section 82.2.13 of <xref target="IEEE802.3"/> ), and</t>
</li> </li>
<li> <li>
<t>PCS lane reordering (section 82.2.14 of <xref target="IEEE802.3 "/>)</t> <t>PCS lane reordering (Section 82.2.14 of <xref target="IEEE802.3 "/>).</t>
</li> </li>
</ul> </ul>
<t>The PSN-bound NSP function is also responsible to detect 40GBASE-R, <t>The PSN-bound NSP function is also responsible for detecting attach
50GBASE-R and 100GBASE-R specific attachment circuit faults such as LOS and los ment circuit faults specific to 40GBASE-R, 50GBASE-R, and 100GBASE-R such as LO
s of alignment.</t> S and loss of alignment.</t>
<t>The PSN-bound IWF is mapping the serialized and scrambled 64B/66B c <t>The PSN-bound IWF maps the serialized and scrambled 64B/66B code st
ode stream including the alignment markers into the basic PLE payload.</t> ream including the alignment markers into the basic PLE payload.</t>
<t>The CE-bound NSP function MUST perform</t> <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>PCS code sync (section 82.2.12 of <xref target="IEEE802.3"/>)</ t> <t>PCS code sync (Section 82.2.12 of <xref target="IEEE802.3"/>),< /t>
</li> </li>
<li> <li>
<t>alignment marker removal (section 82.2.15 of <xref target="IEEE 802.3"/>)</t> <t>alignment-marker removal (Section 82.2.15 of <xref target="IEEE 802.3"/>), and</t>
</li> </li>
<li> <li>
<t>descrambling (section 49.2.10 of <xref target="IEEE802.3"/>)</t > <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t >
</li> </li>
</ul> </ul>
<t>in order to properly</t> <t>in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transform invalid 66B code blocks into proper error control cha racters /E/ (section 82.2.3.10 of <xref target="IEEE802.3"/>)</t> <t>transform invalid 66B code blocks into proper error control cha racters /E/ (Section 82.2.3.10 of <xref target="IEEE802.3"/>) and</t>
</li> </li>
<li> <li>
<t>insert Local Fault (LF) ordered sets (section 81.3.4 of <xref t <t>insert LF ordered sets (Section 81.3.4 of <xref target="IEEE802
arget="IEEE802.3"/>) when the CE-bound IWF is in PLOS state or when PLE packets .3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received w
are received with the L-bit being set</t> ith the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid 66B code blocks typically are a consequence of the CE <aside>
-bound IWF inserting replacement data in case of lost PLE packets, or if the far <t>Note: Invalid 66B code blocks typically are a consequence of the CE
-end PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC -bound IWF inserting replacement data in case of lost PLE packets or the far-end
errors.</t> PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC
<t>When sending the bit stream to the CE, the CE-bound NSP function MU errors.</t></aside>
ST also perform</t> <t>When sending the bit-stream to the CE, the CE-bound NSP function <b
cp14>MUST</bcp14> also perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>scrambling of the 64B/66B code (section 49.2.6 of <xref target= "IEEE802.3"/>)</t> <t>scrambling of the 64B/66B code (Section 49.2.6 of <xref target= "IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>block distribution (section 82.2.6 of <xref target="IEEE802.3"/ >)</t> <t>block distribution (Section 82.2.6 of <xref target="IEEE802.3"/ >), and</t>
</li> </li>
<li> <li>
<t>alignment marker insertion (sections 82.2.7 and 133.2.2 of <xre f target="IEEE802.3"/>)</t> <t>alignment-marker insertion (Sections 82.2.7 and 133.2.2 of <xre f target="IEEE802.3"/>).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="gbase-r-and-400gbase-r"> <section anchor="gbase-r-and-400gbase-r">
<name>200GBASE-R and 400GBASE-R</name> <name>200GBASE-R and 400GBASE-R</name>
<t>The PCS layers of 200GBASE-R and 400GBASE-R defined in section 119 <t>The PCS layers of 200GBASE-R and 400GBASE-R (defined in Section 119
of <xref target="IEEE802.3"/> are based on a 64B/66B code transcoded to a 256B/2 of <xref target="IEEE802.3"/>) are based on a 64B/66B code transcoded to a 256B
57B code to reduce the overhead and make room for a mandatory FEC.</t> /257B code to reduce the overhead and make room for a mandatory FEC.</t>
<t>To gain access to the 64B/66B code stream the PSN-bound NSP further <t>To gain access to the 64B/66B code stream, the PSN-bound NSP furthe
MUST perform</t> r <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>alignment lock and de-skew (section 119.2.5.1 of <xref target=" IEEE802.3"/>)</t> <t>alignment lock and de-skew (Section 119.2.5.1 of <xref target=" IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>PCS Lane reordering and de-interleaving (section 119.2.5.2 of < xref target="IEEE802.3"/>)</t> <t>PCS lane reordering and de-interleaving (Section 119.2.5.2 of < xref target="IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>FEC decoding (section 119.2.5.3 of <xref target="IEEE802.3"/>)< /t> <t>FEC decoding (Section 119.2.5.3 of <xref target="IEEE802.3"/>), </t>
</li> </li>
<li> <li>
<t>post-FEC interleaving (section 119.2.5.4 of <xref target="IEEE8 02.3"/>)</t> <t>post-FEC interleaving (Section 119.2.5.4 of <xref target="IEEE8 02.3"/>),</t>
</li> </li>
<li> <li>
<t>alignment marker removal (section 119.2.5.5 of <xref target="IE EE802.3"/>)</t> <t>alignment-marker removal (Section 119.2.5.5 of <xref target="IE EE802.3"/>),</t>
</li> </li>
<li> <li>
<t>descrambling (section 119.2.5.6 of <xref target="IEEE802.3"/>)< /t> <t>descrambling (Section 119.2.5.6 of <xref target="IEEE802.3"/>), and</t>
</li> </li>
<li> <li>
<t>reverse transcoding from 256B/257B to 64B/66B (section 119.2.5. 7 of <xref target="IEEE802.3"/>)</t> <t>reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5. 7 of <xref target="IEEE802.3"/>).</t>
</li> </li>
</ul> </ul>
<t>Further the PSN-bound NSP MUST perform rate compensation and scramb <t>Further, the PSN-bound NSP <bcp14>MUST</bcp14> perform rate compens
ling (section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF is ation and scrambling (Section 49.2.6 of <xref target="IEEE802.3"/>) before the P
mapping the same into the basic PLE payload.</t> SN-bound IWF maps the same into the basic PLE payload.</t>
<t>Rate compensation is applied so that the rate of the 66B encoded bi <t>Rate compensation is applied so that the rate of the 66B encoded bi
t stream carried by PLE is 528/544 times the nominal bitrate of the 200GBASE-R o t-stream carried by PLE is 528/544 times the nominal bitrate of the 200GBASE-R o
r 400GBASE-R at the PMA service interface. X number of 66 byte long rate compens r 400GBASE-R at the PMA service interface. X number of 66-byte-long rate compens
ation blocks are inserted every X*20479 number of 66B client blocks. For 200GBAS ation blocks are inserted every X*20479 number of 66B client blocks. For 200GBAS
E-R the value of X is 16 and for 400GBASE-R the value of X is 32. Rate compensat E-R, the value of X is 16; for 400GBASE-R, the value of X is 32. Rate compensati
ion blocks are special 66B control characters of type 0x00 that can easily be se on blocks are special 66B control characters of type 0x00 that can easily be sea
arched for by the CE-bound IWF in order to remove them.</t> rched for by the CE-bound IWF in order to remove them.</t>
<t>The PSN-bound NSP function is also responsible to detect 200GBASE-R <t>The PSN-bound NSP function is also responsible for detecting attach
and 400GBASE-R specific attachment circuit faults such as LOS and loss of align ment circuit faults specific to 200GBASE-R and 400GBASE-R such as LOS and loss o
ment.</t> f alignment.</t>
<t>The CE-bound NSP function MUST perform</t> <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>PCS code sync (section 49.2.13 of <xref target="IEEE802.3"/>)</ t> <t>PCS code sync (Section 49.2.13 of <xref target="IEEE802.3"/>),< /t>
</li> </li>
<li> <li>
<t>descrambling (section 49.2.10 of <xref target="IEEE802.3"/>)</t > <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>), a nd</t>
</li> </li>
<li> <li>
<t>rate compensation block removal</t> <t>rate compensation block removal</t>
</li> </li>
</ul> </ul>
<t>in order to properly</t> <t>in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transform invalid 66B code blocks into proper error control cha racters /E/ (section 119.2.3.9 of <xref target="IEEE802.3"/>)</t> <t>transform invalid 66B code blocks into proper error control cha racters /E/ (Section 119.2.3.9 of <xref target="IEEE802.3"/>) and</t>
</li> </li>
<li> <li>
<t>insert Local Fault (LF) ordered sets (section 81.3.4 of <xref t arget="IEEE802.3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</t> <t>insert LF ordered sets (Section 81.3.4 of <xref target="IEEE802 .3"/>) when the CE-bound IWF is in PLOS state or when PLE packets are received w ith the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid 66B code blocks typically are a consequence of the CE <aside>
-bound IWF inserting replacement data in case of lost PLE packets, or if the far <t>Note: Invalid 66B code blocks typically are a consequence of the CE
-end PSN-bound NSP function did set sync headers to 11 due to uncorrectable FEC -bound IWF inserting replacement data in case of lost PLE packets or the far-end
errors.</t> PSN-bound NSP function not setting sync headers to 11 due to uncorrectable FEC
<t>When sending the bit stream to the CE, the CE-bound NSP function MU errors.</t></aside>
ST also perform</t> <t>When sending the bit-stream to the CE, the CE-bound NSP function <b
cp14>MUST</bcp14> also perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transcoding from 64B/66B to 256B/257B (section 119.2.4.2 of <xr ef target="IEEE802.3"/>)</t> <t>transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of <xr ef target="IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>scrambling (section 119.2.4.3 of <xref target="IEEE802.3"/>)</t > <t>scrambling (Section 119.2.4.3 of <xref target="IEEE802.3"/>),</ t>
</li> </li>
<li> <li>
<t>alignment marker insertion (section 119.2.4.4 of <xref target=" IEEE802.3"/>)</t> <t>alignment-marker insertion (Section 119.2.4.4 of <xref target=" IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>pre-FEC distribution (section 119.2.4.5 of <xref target="IEEE80 2.3"/>)</t> <t>pre-FEC distribution (Section 119.2.4.5 of <xref target="IEEE80 2.3"/>),</t>
</li> </li>
<li> <li>
<t>FEC encoding (section 119.2.4.6 of <xref target="IEEE802.3"/>)< /t> <t>FEC encoding (Section 119.2.4.6 of <xref target="IEEE802.3"/>), and</t>
</li> </li>
<li> <li>
<t>PCS Lane distribution (section 119.2.4.8 of <xref target="IEEE8 02.3"/>)</t> <t>PCS lane distribution (Section 119.2.4.8 of <xref target="IEEE8 02.3"/>).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="energy-efficient-ethernet-eee"> <section anchor="energy-efficient-ethernet-eee">
<name>Energy Efficient Ethernet (EEE)</name> <name>Energy Efficient Ethernet (EEE)</name>
<t>Section 78 of <xref target="IEEE802.3"/> does define the optional L ow Power Idle (LPI) capability for Ethernet. Two modes are defined</t> <t>Section 78 of <xref target="IEEE802.3"/> defines the optional LPI c apability for Ethernet. Two modes are defined:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>deep sleep</t> <t>deep sleep</t>
</li> </li>
<li> <li>
<t>fast wake</t> <t>fast wake</t>
</li> </li>
</ul> </ul>
<t>Deep sleep mode is not compatible with PLE due to the CE ceasing tr <t>Deep sleep mode is not compatible with PLE due to the CE ceasing tr
ansmission. Hence there is no support for LPI for 10GBASE-R services across PLE. ansmission. Hence, there is no support for LPI for 10GBASE-R services across PLE
</t> .</t>
<t>When in fast wake mode the CE transmits /LI/ control code blocks in <t>In fast wake mode, the CE transmits /LI/ control code blocks instea
stead of /I/ control code blocks and therefore PLE is agnostic to it. For 25GBAS d of /I/ control code blocks and, therefore, PLE is agnostic to it. For 25GBASE-
E-R and higher services across PLE, LPI is supported as only fast wake mode is a R and higher services across PLE, LPI is supported as only fast wake mode is app
pplicable.</t> licable.</t>
</section> </section>
</section> </section>
<section anchor="sonetsdh-services"> <section anchor="sonetsdh-services">
<name>SONET/SDH Services</name> <name>SONET/SDH Services</name>
<t>SONET/SDH services are special cases of the structured bit stream def <t>SONET/SDH services are special cases of the structured bit-stream def
ined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t> ined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
<t>SDH interfaces are defined in <xref target="G.707"/> and SONET interf <t>SDH interfaces are defined in <xref target="G.707"/>; SONET interface
aces are defined in <xref target="GR253"/>.</t> s are defined in <xref target="GR253"/>.</t>
<t>The PSN-bound NSP function does not modify the received data but is r <t>The PSN-bound NSP function does not modify the received data but is r
esponsible to detect SONET/SDH interface specific attachment circuit faults such esponsible for detecting attachment circuit faults specific to SONET/SDH such as
as LOS, LOF and OOF.</t> LOS, LOF, and OOF.</t>
<t>Data received by the PSN-bound IWF is mapped into the basic PLE paylo ad without any awareness of SONET/SDH frames.</t> <t>Data received by the PSN-bound IWF is mapped into the basic PLE paylo ad without any awareness of SONET/SDH frames.</t>
<t>When the CE-bound IWF is in PLOS state or when PLE packets are receiv ed with the L-bit being set, the CE-bound NSP function is responsible for genera ting the</t> <t>When the CE-bound IWF is in PLOS state or when PLE packets are receiv ed with the L bit set, the CE-bound NSP function is responsible for generating t he:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>MS-AIS maintenance signal defined in section 6.2.4.1.1 of <xref t arget="G.707"/> for SDH services</t> <t>MS-AIS maintenance signal (defined in Section 6.2.4.1.1 of <xref target="G.707"/>) for SDH services and</t>
</li> </li>
<li> <li>
<t>AIS-L maintenance signal defined in section 6.2.1.2 of <xref targ et="GR253"/> for SONET services</t> <t>AIS-L maintenance signal (defined in Section 6.2.1.2 of <xref tar get="GR253"/>) for SONET services</t>
</li> </li>
</ul> </ul>
<t>at client frame boundaries.</t> <t>at client-frame boundaries.</t>
</section> </section>
<section anchor="fibre-channel-services"> <section anchor="fibre-channel-services">
<name>Fibre Channel Services</name> <name>Fibre Channel Services</name>
<t>Fibre Channel services are special cases of the structured bit stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t> <t>Fibre Channel services are special cases of the structured bit-stream defined in <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
<t>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 <xref target="IEEE802.3"/>.</t> <t>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 <xref target="IEEE802.3"/>.</t>
<t>Over time many different Fibre Channel interface types have been spec ified with a varying set of characteristics such as optional vs mandatory FEC an d single-lane vs multi-lane transmission.</t> <t>Over time, many different Fibre Channel interface types have been spe cified with a varying set of characteristics such as optional versus mandatory F EC and single-lane versus multi-lane transmission.</t>
<t>Speed negotiation is not supported by PLE.</t> <t>Speed negotiation is not supported by PLE.</t>
<t>All Fibre Channel services are leveraging the basic PLE payload and i nterface specific mechanisms are confined to the respective service specific NSP functions.</t> <t>All Fibre Channel services leverage the basic PLE payload, and interf ace-specific mechanisms are confined to the respective service-specific NSP func tions.</t>
<section anchor="gfc-2gfc-4gfc-and-8gfc"> <section anchor="gfc-2gfc-4gfc-and-8gfc">
<name>1GFC, 2GFC, 4GFC and 8GFC</name> <name>1GFC, 2GFC, 4GFC, and 8GFC</name>
<t><xref target="FC-PI-2"/> specifies 1GFC and 2GFC. <xref target="FC- <t><xref target="FC-PI-2"/> specifies 1GFC and 2GFC. <xref target="FC-
PI-5"/> and <xref target="FC-PI-5am1"/> do define 4GFC and 8GFC.</t> PI-5"/> and <xref target="FC-PI-5am1"/> define 4GFC and 8GFC.</t>
<t>The PSN-bound NSP function is responsible to detect Fibre Channel s <t>The PSN-bound NSP function is responsible for detecting attachment
pecific attachment circuit faults such as LOS and sync loss.</t> circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
<t>The PSN-bound IWF is mapping the received 8B/10B code stream as is <t>The PSN-bound IWF maps the received 8B/10B code stream as is direct
directly into the basic PLE payload.</t> ly into the basic PLE payload.</t>
<t>The CE-bound NSP function MUST perform transmission word sync in or <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform transmission
der to properly</t> word sync in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>replace invalid transmission words with the special character K 30.7</t> <t>replace invalid transmission words with the special character K 30.7 and</t>
</li> </li>
<li> <li>
<t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</t> <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid transmission words typically are a consequence of the <aside>
CE-bound IWF inserting replacement data in case of lost PLE packets.</t> <t>Note: Invalid transmission words typically are a consequence of the
<t><xref target="FC-PI-5am1"/> does define the use of scrambling for 8 CE-bound IWF inserting replacement data in case of lost PLE packets.</t></aside
GFC, in this case the CE-bound NSP MUST also perform descrambling before replaci >
ng invalid transmission words or inserting NOS ordered sets. And before sending <t><xref target="FC-PI-5am1"/> defines the use of scrambling for 8GFC;
the bit stream to the, the CE-bound NSP function MUST scramble the 8B/10B code s in this case, the CE-bound NSP <bcp14>MUST</bcp14> also perform descrambling be
tream.</t> fore replacing invalid transmission words or inserting NOS ordered sets. Before
sending the bit-stream to the CE, the CE-bound NSP function <bcp14>MUST</bcp14>
scramble the 8B/10B code stream.</t>
</section> </section>
<section anchor="gfc"> <section anchor="gfc">
<name>16GFC</name> <name>16GFC</name>
<t><xref target="FC-PI-5"/> and <xref target="FC-PI-5am1"/> specify 16 <t><xref target="FC-PI-5"/> and <xref target="FC-PI-5am1"/> specify 16
GFC and define a optional FEC layer.</t> GFC and define an optional FEC layer.</t>
<t>If FEC is present it must be indicated via transmitter training sig <t>If FEC is present, it must be indicated via TTS when the attachment
nal (TTS) during attachment circuit bring up. Further the PSN-bound NSP function circuit is brought up. Further, the PSN-bound NSP function <bcp14>MUST</bcp14>
MUST terminate the FEC and the CE-bound NSP function must generate the FEC.</t> terminate the FEC and the CE-bound NSP function must generate the FEC.</t>
<t>The PSN-bound NSP function is responsible to detect Fibre Channel s <t>The PSN-bound NSP function is responsible for detecting attachment
pecific attachment circuit faults such as LOS and sync loss.</t> circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
<t>The PSN-bound IWF is mapping the received scrambled 64B/66B code st <t>The PSN-bound IWF maps the received scrambled 64B/66B code stream a
ream as is into the basic PLE payload.</t> s is into the basic PLE payload.</t>
<t>The CE-bound NSP function MUST perform</t> <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transmission word sync (section 49.2.13 of <xref target="IEEE80 2.3"/>)</t> <t>transmission word sync (Section 49.2.13 of <xref target="IEEE80 2.3"/>) and</t>
</li> </li>
<li> <li>
<t>descrambling (section 49.2.10 of <xref target="IEEE802.3"/>)</t > <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t >
</li> </li>
</ul> </ul>
<t>in order to properly</t> <t>in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>replace invalid transmission words with the error transmission word 1Eh</t> <t>replace invalid transmission words with the error transmission word 1Eh and</t>
</li> </li>
<li> <li>
<t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</t> <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid transmission words typically are a consequence of the <aside>
CE-bound IWF inserting replacement data in case of lost PLE packets, or if the <t>Note: Invalid transmission words typically are a consequence of the
far-end PSN-bound NSP function did set sync headers to 11 due to uncorrectable F CE-bound IWF inserting replacement data in case of lost PLE packets or the far-
EC errors.</t> end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable F
<t>Before sending the bit stream to the CE, the CE-bound NSP function EC errors.</t></aside>
MUST also scramble the 64B/66B code stream (section 49.2.6 of <xref target="IEEE <t>Before sending the bit-stream to the CE, the CE-bound NSP function
802.3"/>).</t> <bcp14>MUST</bcp14> also scramble the 64B/66B code stream (Section 49.2.6 of <xr
ef target="IEEE802.3"/>).</t>
</section> </section>
<section anchor="gfc-and-4-lane-128gfc"> <section anchor="gfc-and-4-lane-128gfc">
<name>32GFC and 4-lane 128GFC</name> <name>32GFC and 4-Lane 128GFC</name>
<t><xref target="FC-PI-6"/> specifies 32GFC and <xref target="FC-PI-6P "/> specifies 4-lane 128GFC, both with FEC layer and TTS support being mandatory .</t> <t><xref target="FC-PI-6"/> specifies 32GFC and <xref target="FC-PI-6P "/> specifies 4-lane 128GFC, both with FEC layer and TTS support being mandatory .</t>
<t>To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform</t> <t>To gain access to the 64B/66B code stream the PSN-bound NSP further <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>descrambling (section of 49.2.10 of <xref target="IEEE802.3"/>) </t> <t>descrambling (Section of 49.2.10 of <xref target="IEEE802.3"/>) ,</t>
</li> </li>
<li> <li>
<t>FEC decoding (section 91.5.3.3 of <xref target="IEEE802.3"/>)</ t> <t>FEC decoding (Section 91.5.3.3 of <xref target="IEEE802.3"/>), and</t>
</li> </li>
<li> <li>
<t>reverse transcoding from 256B/257B to 64B/66B (section 119.2.5. 7 of <xref target="IEEE802.3"/>)</t> <t>reverse transcoding from 256B/257B to 64B/66B (Section 119.2.5. 7 of <xref target="IEEE802.3"/>).</t>
</li> </li>
</ul> </ul>
<!--
HIDDEN COMMENT: per FC-FS-4, same RS-FEC as 100GE but transcoder from 200GE and
400GE (802.3 section 119) where first 5 bits are not scrambled.
<t>Further the PSN-bound NSP MUST perform scrambling (section 49.2.6 of <xref ta <t>Further, the PSN-bound NSP <bcp14>MUST</bcp14> perform scrambling (Section 49
rget="IEEE802.3"/>) before the PSN-bound IWF is mapping the same into the basic .2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF maps the same into
PLE payload.</t> the basic PLE payload.</t>
<t>The PSN-bound NSP function is also responsible to detect Fibre Chan <t>The PSN-bound NSP function is also responsible for detecting attach
nel specific attachment circuit faults such as LOS and sync loss.</t> ment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t
<t>The CE-bound NSP function MUST perform</t> >
<t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transmission word sync (section 119.2.6.3 of <xref target="IEEE 802.3"/>)</t> <t>transmission word sync (Section 119.2.6.3 of <xref target="IEEE 802.3"/>) and</t>
</li> </li>
<li> <li>
<t>descrambling (section 49.2.10 of <xref target="IEEE802.3"/>)</t > <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t >
</li> </li>
</ul> </ul>
<t>in order to properly</t> <t>in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>replace invalid transmission words with the error transmission word 1Eh</t> <t>replace invalid transmission words with the error transmission word 1Eh and</t>
</li> </li>
<li> <li>
<t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</t> <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid transmission words typically are a consequence of the <aside>
CE-bound IWF inserting replacement data in case of lost PLE packets, or if the <t>Note: Invalid transmission words typically are a consequence of the
far-end PSN-bound NSP function did set sync headers to 11 due to uncorrectable F CE-bound IWF inserting replacement data in case of lost PLE packets or the far-
EC errors.</t> end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable F
<t>When sending the bit stream to the CE, the CE-bound NSP function MU EC errors.</t></aside>
ST also perform</t> <t>When sending the bit-stream to the CE, the CE-bound NSP function <b
cp14>MUST</bcp14> also perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transcoding from 64B/66B to 256B/257B (section 119.2.4.2 of <xr ef target="IEEE802.3"/>)</t> <t>transcoding from 64B/66B to 256B/257B (Section 119.2.4.2 of <xr ef target="IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>FEC encoding (section 91.5.2.7 of <xref target="IEEE802.3"/>)</ t> <t>FEC encoding (Section 91.5.2.7 of <xref target="IEEE802.3"/>), and</t>
</li> </li>
<li> <li>
<t>scrambling (section 49.2.6 of <xref target="IEEE802.3"/>)</t> <t>scrambling (Section 49.2.6 of <xref target="IEEE802.3"/>).</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="gfc-1"> <section anchor="gfc-1">
<name>64GFC</name> <name>64GFC</name>
<!--
HIDDEN COMMENT: per FC-FS-5 64GFC does leverage RS-FEC 50GE functions defined in
802.3 section 134
<t><xref target="FC-PI-7"/> specifies 64GFC with a mandatory FEC layer.</t> <t><xref target="FC-PI-7"/> specifies 64GFC with a mandatory FEC layer.</t>
<t>To gain access to the 64B/66B code stream the PSN-bound NSP further MUST perform</t> <t>To gain access to the 64B/66B code stream, the PSN-bound NSP furthe r <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>alignment lock (section 134.5.4 of <xref target="IEEE802.3"/> m odified to single FEC lane operation)</t> <t>alignment lock (Section 134.5.4 of <xref target="IEEE802.3"/> m odified to single FEC lane operation),</t>
</li> </li>
<li> <li>
<t>FEC decoding (section 134.5.3.3 of <xref target="IEEE802.3"/>)< /t> <t>FEC decoding (Section 134.5.3.3 of <xref target="IEEE802.3"/>), </t>
</li> </li>
<li> <li>
<t>alignment marker removal (section 134.5.3.4 of <xref target="IE EE802.3"/>)</t> <t>alignment-marker removal (Section 134.5.3.4 of <xref target="IE EE802.3"/>), and</t>
</li> </li>
<li> <li>
<t>reverse transcoding from 256B/257B to 64B/66B (section 91.5.3.5 of <xref target="IEEE802.3"/>)</t> <t>reverse transcoding from 256B/257B to 64B/66B (Section 91.5.3.5 of <xref target="IEEE802.3"/>).</t>
</li> </li>
</ul> </ul>
<t>Further the PSN-bound NSP MUST perform scrambling (section 49.2.6 o <t>Further, the PSN-bound NSP <bcp14>MUST</bcp14> perform scrambling (
f <xref target="IEEE802.3"/>) before the PSN-bound IWF is mapping the same into Section 49.2.6 of <xref target="IEEE802.3"/>) before the PSN-bound IWF maps the
the basic PLE payload.</t> same into the basic PLE payload.</t>
<t>The PSN-bound NSP function is also responsible to detect Fibre Chan <t>The PSN-bound NSP function is also responsible for detecting attach
nel specific attachment circuit faults such as LOS and sync loss.</t> ment circuit faults specific to the Fibre Channel such as LOS and sync loss.</t>
<t>The CE-bound NSP function MUST perform</t> <t>The CE-bound NSP function <bcp14>MUST</bcp14> perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transmission word sync (section 49.2.13 of <xref target="IEEE80 2.3"/>)</t> <t>transmission word sync (Section 49.2.13 of <xref target="IEEE80 2.3"/>) and</t>
</li> </li>
<li> <li>
<t>descrambling (section 49.2.10 of <xref target="IEEE802.3"/>)</t > <t>descrambling (Section 49.2.10 of <xref target="IEEE802.3"/>)</t >
</li> </li>
</ul> </ul>
<t>in order to properly</t> <t>in order to properly:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>replace invalid transmission words with the error transmission word 1Eh</t> <t>replace invalid transmission words with the error transmission word 1Eh and</t>
</li> </li>
<li> <li>
<t>insert Not Operational (NOS) ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L-bit being set</t> <t>insert NOS ordered sets when the CE-bound IWF is in PLOS state or when PLE packets are received with the L bit set.</t>
</li> </li>
</ul> </ul>
<t>Note: Invalid transmission words typically are a consequence of the <aside>
CE-bound IWF inserting replacement data in case of lost PLE packets, or if the <t>Note: Invalid transmission words typically are a consequence of the
far-end PSN-bound NSP function did set sync headers to 11 due to uncorrectable F CE-bound IWF inserting replacement data in case of lost PLE packets or the far
EC errors.</t> -end PSN-bound NSP function not setting sync headers to 11 due to uncorrectable
<t>When sending the bit stream to the CE, the CE-bound NSP function MU FEC errors.</t></aside>
ST also perform</t> <t>When sending the bit-stream to the CE, the CE-bound NSP function <b
cp14>MUST</bcp14> also perform:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>transcoding from 64B/66B to 256B/257B (section 91.5.2.5 of <xre f target="IEEE802.3"/>)</t> <t>transcoding from 64B/66B to 256B/257B (Section 91.5.2.5 of <xre f target="IEEE802.3"/>),</t>
</li> </li>
<li> <li>
<t>alignment marker insertion (section 134.5.2.6 of <xref target=" IEEE802.3"/>)</t> <t>alignment-marker insertion (Section 134.5.2.6 of <xref target=" IEEE802.3"/>), and</t>
</li> </li>
<li> <li>
<t>FEC encoding (section 134.5.2.7 of <xref target="IEEE802.3"/>)< /t> <t>FEC encoding (Section 134.5.2.7 of <xref target="IEEE802.3"/>). </t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="otn-services"> <section anchor="otn-services">
<name>OTN Services</name> <name>OTN Services</name>
<t>OTN services are special cases of the structured bit stream defined i n <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t> <t>OTN services are special cases of the structured bit-stream defined i n <xref section="3.3.4" sectionFormat="of" target="RFC3985"/>.</t>
<t>OTN interfaces are defined in <xref target="G.709"/>.</t> <t>OTN interfaces are defined in <xref target="G.709"/>.</t>
<t>The PSN-bound NSP function MUST terminate the FEC and replace the OTU k overhead in row 1 columns 8-14 with all-zeros pattern which results in a exten ded ODUk frame as illustrated in <xref target="extodukframe"/>. The frame alignm ent overhead (FA OH) in row 1 columns 1-7 is kept as it is.</t> <t>The PSN-bound NSP function <bcp14>MUST</bcp14> 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 <xref target="extodukframe" />. The frame alignment overhead (FA OH) in row 1, columns 1-7 is kept as it is. </t>
<figure anchor="extodukframe"> <figure anchor="extodukframe">
<name>Extended ODUk Frame</name> <name>Extended ODUk Frame</name>
<artwork><![CDATA[ <artwork><![CDATA[
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 | | |
skipping to change at line 738 skipping to change at line 597
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| | |
+-----------------+------------------- .. --------------------+ +-----------------+------------------- .. --------------------+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The PSN-bound NSP function is also responsible to detect OTUk specifi <t>The PSN-bound NSP function is also responsible for detecting attachme
c attachment circuit faults such as LOS, LOF, LOM and AIS.</t> nt circuit faults specific to OTUk such as LOS, LOF, LOM, and AIS.</t>
<t>The PSN-bound IWF is mapping the extended ODUk frame into the byte al <t>The PSN-bound IWF maps the extended ODUk frame into the byte-aligned
igned PLE payload.</t> PLE payload.</t>
<t>The CE-bound NSP function will recover the ODUk by searching for the <t>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 frame alignment overhead in the extended ODUk received from the CE-bound IWF and
generates the FEC.</t> generating the FEC.</t>
<t>When the CE-bound IWF is in PLOS state or when PLE packets are receiv <t>When the CE-bound IWF is in PLOS state or when PLE packets are receiv
ed with the L-bit being set, the CE-bound NSP function is responsible for genera ed with the L bit set, the CE-bound NSP function is responsible for generating t
ting the ODUk-AIS maintenance signal defined in section 16.5.1 of <xref target=" he ODUk-AIS maintenance signal defined in Section 16.5.1 of <xref target="G.709"
G.709"/> at client frame boundaries.</t> /> at client-frame boundaries.</t>
</section> </section>
</section> </section>
<section anchor="ple-encapsulation-layer"> <section anchor="ple-encapsulation-layer">
<name>PLE Encapsulation Layer</name> <name>PLE Encapsulation Layer</name>
<t>The basic packet format used by PLE is shown in the <xref target="encap "/>.</t> <t>The basic packet format used by PLE is shown in <xref target="encap"/>. </t>
<figure anchor="encap"> <figure anchor="encap">
<name>PLE Encapsulation Layer</name> <name>PLE Encapsulation Layer</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-------------------------------+ -+ +-------------------------------+ -+
| 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
| | / | | /
+-------------------------------+ --+ +-------------------------------+ --+
]]></artwork> ]]></artwork>
</figure> </figure>
<section anchor="psn-and-vpws-demultiplexing-headers"> <section anchor="psn-and-vpws-demultiplexing-headers">
<name>PSN and VPWS Demultiplexing Headers</name> <name>PSN and VPWS Demultiplexing Headers</name>
<t>This document does not imply any specific technology to be used for i <t>This document does not suggest any specific technology be used for im
mplementing the VPWS demultiplexing and PSN layers.</t> plementing the VPWS demultiplexing and PSN layers.</t>
<t>The total size of a PLE packet for a specific PW MUST NOT exceed the <t>The total size of a PLE packet for a specific PW <bcp14>MUST NOT</bcp
path MTU between the pair of PEs terminating this PW.</t> 14> exceed the path MTU between the pair of PEs terminating this PW.</t>
<t>When a MPLS PSN layer is used, a VPWS label provides the demultiplexi <t>When an MPLS PSN layer is used, a VPWS label provides the demultiplex
ng mechanism as described in <xref section="5.4.2" sectionFormat="of" target="RF ing mechanism (as described in <xref section="5.4.2" sectionFormat="of" target="
C3985"/>. The PSN tunnel can be a simple best path Label Switched Path (LSP) est RFC3985"/>). The PSN tunnel can be a simple best-path LSP established using LDP
ablished using LDP <xref target="RFC5036"/> or Segment Routing (SR) <xref target (see <xref target="RFC5036"/>) or Segment Routing (SR) (see <xref target="RFC840
="RFC8402"/> or a traffic engineered LSP established using RSVP-TE <xref target= 2"/>); or it can be a traffic-engineered LSP established using RSVP-TE (see <xre
"RFC3209"/> or SR policies <xref target="RFC9256"/>.</t> f target="RFC3209"/>) or SR policies (see <xref target="RFC9256"/>).</t>
<t>When a SRv6 PSN layer is used, a SRv6 service segment identifier (SID <t>When an SRv6 PSN layer is used, an SRv6 service SID (as defined in <x
) as defined in <xref target="RFC8402"/> does provide the demultiplexing mechani ref target="RFC8402"/>) provides the demultiplexing mechanism and definitions of
sm and definitions of <xref section="6" sectionFormat="of" target="RFC9252"/> do <xref section="6" sectionFormat="of" target="RFC9252"/> apply. Both SRv6 servic
apply. Both SRv6 service SIDs with the full IPv6 address format defined in <xre e SIDs with the full IPv6 address format defined in <xref target="RFC8986"/> and
f target="RFC8986"/> and compressed SIDs (C-SIDs) with format defined in <xref t compressed SIDs (C-SIDs) with the format defined in <xref target="RFC9800"/> ca
arget="I-D.draft-ietf-spring-srv6-srh-compression"/> can be used.</t> n be used.</t>
<section anchor="new-srv6-behaviors"> <section anchor="new-srv6-behaviors">
<name>New SRv6 Behaviors</name> <name>New SRv6 Behaviors</name>
<t>Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are <t>Two new encapsulation behaviors, H.Encaps.L1 and H.Encaps.L1.Red, a
defined in this document. The behavior procedures are applicable to both SIDs a re defined in this document. The behavior procedures are applicable to both SIDs
nd C-SIDs.</t> and C-SIDs.</t>
<t>The H.Encaps.L1 behavior encapsulates a frame received from an IWF <t>The H.Encaps.L1 behavior encapsulates a frame received from an IWF
in a IPv6 packet with an segment routing header (SRH). The received frame become in an IPv6 packet with a segment routing header (SRH). The received frame become
s the payload of the new IPv6 packet.</t> s the payload of the new IPv6 packet.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The next header field of the SRH or the last extension header p resent MUST be set to TBA1.</t> <t>The next header field of the SRH or the last extension header p resent <bcp14>MUST</bcp14> be set to 147.</t>
</li> </li>
<li> <li>
<t>The insertion of the SRH MAY be omitted per <xref target="RFC89 86"/> when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.</t> <t>The insertion of the SRH <bcp14>MAY</bcp14> be omitted per <xre f target="RFC8986"/> when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.</t>
</li> </li>
</ul> </ul>
<t>The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.</t> <t>The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>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 IPv6 addre <t>H.Encaps.L1.Red reduces the length of the SRH by excluding the
ss field.</t> first SID in the SRH. The first SID is only placed in the Destination Address fi
eld of the IPv6 header.</t>
</li> </li>
<li> <li>
<t>The insertion of the SRH MAY be omitted per <xref target="RFC89 86"/> when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.</t> <t>The insertion of the SRH <bcp14>MAY</bcp14> be omitted per <xre f target="RFC8986"/> when the SRv6 policy only contains one segment and there is no need to use any flag, tag, or TLV.</t>
</li> </li>
</ul> </ul>
<t>Three new "Endpoint with decapsulation and bit-stream cross-connect <t>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 " behaviors called "End.DX1", "End.DX1 with NEXT-CSID", and "End.DX1 with REPLAC
are defined in this document. These new behaviors are variants of End.DX2 defin E-CSID" are defined in this document. These new behaviors are variants of End.DX
ed in <xref target="RFC8986"/> and all have the following procedures in common.< 2 defined in <xref target="RFC8986"/>, and they all have the following procedure
/t> s in common:</t>
<t>The End.DX1 SID MUST be the last segment in an SR Policy, and it is <t>The End.DX1 SID <bcp14>MUST</bcp14> be the last segment in an SR Po
associated with a CE-bound IWF I. When N receives a packet destined to S and S licy, and it is associated with a CE-bound IWF I. When N receives a packet desti
is a local End.DX1 SID, N does the following:</t> ned to S and S is a local End.DX1 SID, N does the following:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode" markers="false"><![CDATA[
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. }
]]></artwork> ]]></sourcecode>
<t>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:</t> <t>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:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode" markers="false"><![CDATA[
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. }
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="ple-header"> <section anchor="ple-header">
<name>PLE Header</name> <name>PLE Header</name>
<t>The PLE header MUST contain the PLE control word (4 bytes) and MUST i nclude a fixed size RTP header <xref target="RFC3550"/>. The RTP header MUST imm ediately follow the PLE control word.</t> <t>The PLE header <bcp14>MUST</bcp14> contain the PLE control word (4 by tes) and <bcp14>MUST</bcp14> include a fixed-size RTP header <xref target="RFC35 50"/>. The RTP header <bcp14>MUST</bcp14> immediately follow the PLE control wor d.</t>
<section anchor="ple-control-word"> <section anchor="ple-control-word">
<name>PLE Control Word</name> <name>PLE Control Word</name>
<t>The format of the PLE control word is in line with the guidance in <xref target="RFC4385"/> and is shown in <xref target="cw"/>.</t> <t>The format of the PLE control word is in line with the guidance in <xref target="RFC4385"/> and is shown in <xref target="cw"/>.</t>
<figure anchor="cw"> <figure anchor="cw">
<name>PLE Control Word</name> <name>PLE Control Word</name>
<artwork><![CDATA[ <artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The bits 0..3 of the first nibble are set to 0 to differentiate a c ontrol word or Associated Channel Header (ACH) from an IP packet or Ethernet fra me. The first nibble MUST be set to 0000b to indicate that this header is a cont rol word as defined in <xref section="3" sectionFormat="of" target="RFC4385"/>.< /t> <t>The bits 0..3 of the first nibble are set to 0 to differentiate a c ontrol word or ACH from an IP packet or Ethernet frame. The first nibble <bcp14> MUST</bcp14> be set to 0000b to indicate that this header is a control word as d efined in <xref section="3" sectionFormat="of" target="RFC4385"/>.</t>
<t>The other fields in the control word are used as defined below:</t> <t>The other fields in the control word are used as defined below:</t>
<ul spacing="normal"> <dl spacing="normal" newline="true">
<li> <dt>L:</dt>
<t>L</t> <dd>Set by the PE to indicate that data carried in the payload is
</li> invalid due to an attachment circuit fault. The downstream PE <bcp14>MUST</bcp14
</ul> > send appropriate replacement data. The NSP <bcp14>MAY</bcp14> inject an approp
<ul empty="true"> riate specific fault propagation signal.</dd>
<li> <dt>R:</dt>
<t>Set by the PE to indicate that data carried in the payload is i <dd>Set by the downstream PE to indicate that the IWF experiences
nvalid due to an attachment circuit fault. The downstream PE MUST send appropria packet loss from the PSN or a server layer backward fault indication is present
te replacement data. The NSP MAY inject an appropriate native fault propagation in the NSP. The R bit <bcp14>MUST</bcp14> be cleared by the PE once the packet l
signal.</t> oss state or fault indication has cleared.</dd>
</li> <dt>RSV:</dt>
</ul> <dd>These bits are reserved for future use. This field <bcp14>MUST
<ul spacing="normal"> </bcp14> be set to zero by the sender and ignored by the receiver.</dd>
<li> <dt>FRG:</dt>
<t>R</t> <dd>These bits <bcp14>MUST</bcp14> be set to zero by the sender an
</li> d ignored by the receiver as PLE does not use payload fragmentation.</dd>
</ul> <dt>LEN:</dt>
<ul empty="true">
<li> <dd>In accordance with <xref section="3" sectionFormat="of" target
<t>Set by the downstream PE to indicate that the IWF experiences p ="RFC4385"/>, the length field <bcp14>MUST</bcp14> always be set to zero as ther
acket loss from the PSN or a server layer backward fault indication is present i e is no padding added to the PLE packet. The preconfigured size of the PLE payl
n the NSP. The R bit MUST be cleared by the PE once the packet loss state or fau oad <bcp14>MUST</bcp14> be assumed to be as described in <xref target="ple-heade
lt indication has cleared.</t> r"/>; if the actual packet size is inconsistent with this length, the packet <bc
</li> p14>MUST</bcp14> be considered malformed.
</ul>
<ul spacing="normal"> To detect malformed packets the default, preconfigured or signaled
<li> payload size <bcp14>MUST</bcp14> be assumed.</dd>
<t>RSV</t> <dt>Sequence number:</dt>
</li> <dd>The sequence number field is used to provide a common PW seque
</ul> ncing function as well as detection of lost packets. It <bcp14>MUST</bcp14> be g
<ul empty="true"> enerated in accordance with the rules defined in <xref section="5.1" sectionForm
<li> at="of" target="RFC3550"/> and <bcp14>MUST</bcp14> be incremented with every PLE
<t>These bits are reserved for future use. This field MUST be set packet being sent.</dd>
to zero by the sender and ignored by the receiver.</t> </dl>
</li>
</ul>
<ul spacing="normal">
<li>
<t>FRG</t>
</li>
</ul>
<ul empty="true">
<li>
<t>These bits MUST be set to zero by the sender and ignored by the
receiver as PLE does not use payload fragmentation.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>LEN</t>
</li>
</ul>
<ul empty="true">
<li>
<t>In accordance to <xref section="3" sectionFormat="of" target="R
FC4385"/> the length field MUST always be set to zero as there is no padding add
ed to the PLE packet. To detect malformed packets the default, preconfigured or
signaled payload size MUST be assumed.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>Sequence number</t>
</li>
</ul>
<ul empty="true">
<li>
<t>The sequence number field is used to provide a common PW sequen
cing function as well as detection of lost packets. It MUST be generated in acco
rdance with the rules defined in <xref section="5.1" sectionFormat="of" target="
RFC3550"/> and MUST be incremented with every PLE packet being sent.</t>
</li>
</ul>
</section> </section>
<section anchor="rtp-header"> <section anchor="rtp-header">
<name>RTP Header</name> <name>RTP Header</name>
<t>The RTP header MUST be included to explicitly convey timing informa <t>The RTP header <bcp14>MUST</bcp14> be included to explicitly convey
tion.</t> timing information.</t>
<t>The RTP header as defined in <xref target="RFC3550"/> is reused to <t>The RTP header (as defined in <xref target="RFC3550"/>) is reused t
align with other bit-stream emulation pseudowires defined by <xref target="RFC45 o align with other bit-stream emulation pseudowires defined by <xref target="RFC
53"/>, <xref target="RFC5086"/> and <xref target="RFC4842"/> and to allow PLE im 4553"/>, <xref target="RFC5086"/>, and <xref target="RFC4842"/> and to allow PLE
plementations to reuse pre-existing work.</t> implementations to reuse preexisting work.</t>
<t>There is no intention to support full RTP topologies and protocol m <t>There is no intention to support full RTP topologies and protocol m
echanisms, such as header extensions, contributing source (CSRC) list, padding, echanisms, such as header extensions, contributing source (CSRC) list, padding,
RTP Control Protocol (RTCP), RTP header compression, Secure Realtime Transport P RTCP, RTP header compression, SRTP, etc., as these are not applicable to PLE VPW
rotocol (SRTP), etc., are not applicable to PLE VPWS.</t> S.</t>
<t>The format of the RTP header is as shown in <xref target="rtp"/>.</ t> <t>The format of the RTP header is as shown in <xref target="rtp"/>.</ t>
<figure anchor="rtp"> <figure anchor="rtp">
<name>RTP Header</name> <name>RTP Header</name>
<artwork><![CDATA[ <artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<ul spacing="normal"> <dl spacing="normal" newline="true">
<li> <dt>V:</dt><dd><t>Version</t>
<t>V: Version</t> <t>The version field <bcp14>MUST</bcp14> be set to 2.</t>
</li> </dd>
</ul> <dt>P:</dt><dd><t>Padding</t>
<ul empty="true"> <t>The padding flag <bcp14>MUST</bcp14> be set to zero by the send
<li> er and ignored by the receiver.</t>
<t>The version field MUST be set to 2.</t> </dd>
</li> <dt>X:</dt><dd><t>Header extension</t>
</ul> <t>The X bit <bcp14>MUST</bcp14> be set to zero by sender and igno
<ul spacing="normal"> red by receiver.</t>
<li> </dd>
<t>P: Padding</t> <dt>CC:</dt><dd><t>CSRC count</t>
</li> <t>The CC field <bcp14>MUST</bcp14> be set to zero by the sender a
</ul> nd ignored by the receiver.</t>
<ul empty="true"> </dd>
<li> <dt>M:</dt><dd><t>Marker</t>
<t>The padding flag MUST be set to zero by the sender and ignored <t>The M bit <bcp14>MUST</bcp14> be set to zero by the sender and
by the receiver.</t> ignored by the receiver.</t>
</li> </dd>
</ul> <dt>PT:</dt><dd><t>Payload type</t>
<ul spacing="normal">
<li> <t>A PT value <bcp14>MUST</bcp14> be allocated from the range of d
<t>X: Header extension</t> ynamic values defined in <xref section="6" sectionFormat="of" target="RFC3551"/>
</li> for each direction of the VPWS. The same PT value <bcp14>MAY</bcp14> be reused
</ul> for both for directions and between different PLE VPWSs.</t>
<ul empty="true"> <t>The PT field <bcp14>MAY</bcp14> be used for detection of miscon
<li> nections.</t>
<t>The X bit MUST be set to zero by sender and ignored by receiver </dd>
.</t> <dt>Sequence number:</dt>
</li> <dd>When using a 16-bit sequence number space, the sequence number
</ul> in the RTP header <bcp14>MUST</bcp14> be equal to the sequence number in the PL
<ul spacing="normal"> E control word. When using a sequence number space of 32 bits, the initial value
<li> of the RTP sequence number <bcp14>MUST</bcp14> be 0 and incremented whenever th
<t>CC: CSRC count</t> e PLE control word sequence number cycles through from 0xFFFF to 0x0000.</dd>
</li> <dt>Timestamp:</dt>
</ul> <dd>Timestamp values are used in accordance with the rules establi
<ul empty="true"> shed in <xref target="RFC3550"/>. For bit-streams up to 200 Gbps, the frequency
<li> of the clock used for generating timestamps <bcp14>MUST</bcp14> be 125 MHz based
<t>The CC field MUST be set to zero by the sender and ignored by t on a the common clock I. For bit-streams above 200 Gbps, the frequency <bcp14>M
he receiver.</t> UST</bcp14> be 250 MHz.</dd>
</li> <dt>SSRC:</dt><dd><t>Synchronization source</t>
</ul> <t>The SSRC field <bcp14>MAY</bcp14> be used for detection of misc
<ul spacing="normal"> onnections.</t>
<li> </dd>
<t>M: Marker</t> </dl>
</li>
</ul>
<ul empty="true">
<li>
<t>The M bit MUST be set to zero by the sender and ignored by the
receiver.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>PT: Payload type</t>
</li>
</ul>
<ul empty="true">
<li>
<t>A PT value MUST be allocated from the range of dynamic values d
efined in <xref section="6" sectionFormat="of" target="RFC3551"/> for each direc
tion of the VPWS. The same PT value MAY be reused both for direction and between
different PLE VPWS.</t>
</li>
</ul>
<ul empty="true">
<li>
<t>The PT field MAY be used for detection of misconnections.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>Sequence number</t>
</li>
</ul>
<ul empty="true">
<li>
<t>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 bit, the initial value of the RTP seque
nce number MUST be 0 and incremented whenever the PLE control word sequence numb
er cycles through from 0xFFFF to 0x0000.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>Timestamp</t>
</li>
</ul>
<ul empty="true">
<li>
<t>Timestamp values are used in accordance with the rules establis
hed in <xref target="RFC3550"/>. For bit-streams up to 200 Gbps the frequency of
the clock used for generating timestamps MUST be 125 MHz based on a the common
clock I. For bit-streams above 200 Gbps the frequency MUST be 250 MHz.</t>
</li>
</ul>
<ul spacing="normal">
<li>
<t>SSRC: Synchronization source</t>
</li>
</ul>
<ul empty="true">
<li>
<t>The SSRC field MAY be used for detection of misconnections.</t>
</li>
</ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="ple-payload-layer"> <section anchor="ple-payload-layer">
<name>PLE Payload Layer</name> <name>PLE Payload Layer</name>
<t>A bit-stream is mapped into a PLE packet with a fixed payload size whic <t>A bit-stream is mapped into a PLE packet with a fixed payload size, whi
h MUST be defined during VPWS setup, MUST be the same in both directions of the ch <bcp14>MUST</bcp14> be defined during VPWS setup, <bcp14>MUST</bcp14> be the
VPWS and MUST remain unchanged for the lifetime of the VPWS.</t> same in both directions of the VPWS, and <bcp14>MUST</bcp14> remain unchanged fo
<t>All PLE implementations MUST be capable of supporting the default paylo r the lifetime of the VPWS.</t>
ad size of 1024 bytes. The payload size SHOULD be configurable to be able to add <t>All PLE implementations <bcp14>MUST</bcp14> be capable of supporting th
ress specific packetization delay and overhead expectations. The smallest suppor e default payload size of 1024 bytes. The payload size <bcp14>SHOULD</bcp14> be
ted payload size is 64 bytes.</t> configurable to be able to address specific packetization delay and overhead exp
ectations. The smallest supported payload size is 64 bytes.</t>
<section anchor="basic-payload"> <section anchor="basic-payload">
<name>Basic Payload</name> <name>Basic Payload</name>
<t>The PLE payload is filled with incoming bits of the bit-stream starti ng from the most significant to the least significant bit without considering an y structure of the bit-stream.</t> <t>The PLE payload is filled with incoming bits of the bit-stream starti ng from the most significant to the least significant bit without considering an y structure of the bit-stream.</t>
</section> </section>
<section anchor="byte-aligned-payload"> <section anchor="byte-aligned-payload">
<name>Byte aligned Payload</name> <name>Byte-Aligned Payload</name>
<t>The PLE payload is filled in a byte aligned manner, where the order o <t>The PLE payload is filled in a byte-aligned manner, where the order o
f the payload bytes corresponds to their order on the attachment circuit. Consec f the payload bytes corresponds to their order on the attachment circuit. Consec
utive bits coming from the attachment circuit fill each payload byte starting fr utive bits coming from the attachment circuit fill each payload byte starting fr
om most significant bit to least significant. The PLE payload size MUST be an in om most significant bit to least significant. The PLE payload size <bcp14>MUST</
teger number of bytes.</t> bcp14> be an integer number of bytes.</t>
</section> </section>
</section> </section>
<section anchor="ple-operation"> <section anchor="ple-operation">
<name>PLE Operation</name> <name>PLE Operation</name>
<section anchor="common-considerations"> <section anchor="common-considerations">
<name>Common Considerations</name> <name>Common Considerations</name>
<t>A PLE VPWS can be established using manual configuration or leveragin g mechanisms of a signaling protocol.</t> <t>A PLE VPWS can be established using manual configuration or leveragin g mechanisms of a signaling protocol.</t>
<t>Furthermore emulation of bit-stream signals using PLE is only possibl <t>Furthermore, emulation of bit-stream signals using PLE is only possib
e when the two attachment circuits of the VPWS are of the same service type (OC1 le when the two attachment circuits of the VPWS are of the same service type (OC
92, 10GBASE-R, ODU2, etc) and are using the same PLE payload type and payload si 192, 10GBASE-R, ODU2, etc.) and are using the same PLE payload type and payload
ze. This can be ensured via manual configuration or via the mechanisms of a sign size. This can be ensured via manual configuration or via the mechanisms of a si
aling protocol.</t> gnaling protocol.</t>
<t>PLE related control protocol extensions to LDP <xref target="RFC8077" <t>PLE-related control protocol extensions to LDP <xref target="RFC8077"
/> or EVPN-VPWS <xref target="RFC8214"/> are out of scope for this document.</t> /> or EVPN-VPWS <xref target="RFC8214"/> are out of scope for this document.</t>
<t>Extensions for EVPN-VPWS are proposed in <xref target="I-D.draft-schm <t>Extensions for EVPN-VPWS are proposed in <xref target="I-D.schmutzer-
utzer-bess-bitstream-vpws-signalling"/> and for LDP in <xref target="I-D.draft-s bess-bitstream-vpws-signalling"/> and for LDP in <xref target="I-D.schmutzer-pal
chmutzer-pals-ple-signaling"/>.</t> s-ple-signaling"/>.</t>
</section> </section>
<section anchor="ple-iwf-operation"> <section anchor="ple-iwf-operation">
<name>PLE IWF Operation</name> <name>PLE IWF Operation</name>
<section anchor="psn-bound-encapsulation-behavior"> <section anchor="psn-bound-encapsulation-behavior">
<name>PSN-bound Encapsulation Behavior</name> <name>PSN-Bound Encapsulation Behavior</name>
<t>After the VPWS is set up, the PSN-bound IWF does perform the follow <t>After the VPWS is set up, the PSN-bound IWF performs the following
ing steps:</t> steps:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Packetize the data received from the CE is into PLE payloads, a ll of the same configured size</t> <t>Packetize the data received from the CE into PLE payloads, all of the same configured size,</t>
</li> </li>
<li> <li>
<t>Add PLE control word and RTP header with sequence numbers, flag s and timestamps properly set</t> <t>Add PLE control word and RTP header with sequence numbers, flag s, and timestamps properly set,</t>
</li> </li>
<li> <li>
<t>Add the VPWS demultiplexer and PSN headers</t> <t>Add the VPWS demultiplexer and PSN headers,</t>
</li> </li>
<li> <li>
<t>Transmit the resulting packets over the PSN</t> <t>Transmit the resulting packets over the PSN,</t>
</li> </li>
<li> <li>
<t>Set L bit in the PLE control word whenever attachment circuit d etects a fault</t> <t>Set the L bit in the PLE control word whenever the attachment c ircuit detects a fault, and</t>
</li> </li>
<li> <li>
<t>Set R bit in the PLE control word whenever the local CE-bound I WF is in packet loss state</t> <t>Set the R bit in the PLE control word whenever the local CE-bou nd IWF is in packet loss state.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="ce-bound-decapsulation-behavior"> <section anchor="ce-bound-decapsulation-behavior">
<name>CE-bound Decapsulation Behavior</name> <name>CE-Bound Decapsulation Behavior</name>
<t>The CE-bound IWF is responsible for removing the PSN and VPWS demul <t>The CE-bound IWF is responsible for removing the PSN and VPWS demul
tiplexing headers, PLE control word and RTP header from the received packet stre tiplexing headers, PLE control word, and RTP header from the received packet str
am and sending the bit-stream out via the local attachment circuit.</t> eam and sending the bit-stream out via the local attachment circuit.</t>
<t>A de-jitter buffer MUST be implemented where the PLE packets are st <t>A de-jitter buffer <bcp14>MUST</bcp14> be implemented where the PLE
ored upon arrival. The size of this buffer SHOULD be locally configurable to all packets are stored upon arrival. The size of this buffer <bcp14>SHOULD</bcp14>
ow accommodation of specific PSN packet delay variation (PDV) expected.</t> be locally configurable to allow accommodation of specific PSN PDV expected.</t>
<t>The CE-bound IWF SHOULD use the sequence number in the control word <t>The CE-bound IWF <bcp14>SHOULD</bcp14> use the sequence number in t
to detect lost and misordered packets. It MAY use the sequence number in the RT he control word to detect lost and misordered packets. It <bcp14>MAY</bcp14> use
P header for the same purposes. The CE-bound IWF MAY support re-ordering of pack the sequence number in the RTP header for the same purpose. The CE-bound IWF <b
ets received out of order. If the CE-bound IWF does not support re-ordering it M cp14>MAY</bcp14> support reordering of packets received out of order. If the CE-
UST drop the misordered packets.</t> bound IWF does not support reordering, it <bcp14>MUST</bcp14> drop the misordere
<t>The payload of a lost or dropped packet MUST be replaced with equiv d packets.</t>
alent amount of replacement data. The contents of the replacement data MAY be lo <t>The payload of a lost or dropped packet <bcp14>MUST</bcp14> be repl
cally configurable. By default, all PLE implementations MUST support generation aced with an equivalent amount of replacement data. The contents of the replacem
of "0xAA" as replacement data. The alternating sequence of 0s and 1s of the "0xA ent data <bcp14>MAY</bcp14> be locally configurable. By default, all PLE impleme
A" pattern does ensure clock synchronization is maintained and for 64B/66B code ntations <bcp14>MUST</bcp14> support generation of "0xAA" as replacement data. T
based services no invalid sync headers are generated. While sending out the repl he alternating sequence of 0s and 1s of the "0xAA" pattern ensures clock synchro
acement data, the IWF will apply a holdover mechanism to maintain the clock.</t> nization is maintained and, for 64B/66B code-based services, ensures no invalid
<t>Whenever the VPWS is not operationally up, the CE-bound NSP functio sync headers are generated. While sending out the replacement data, the IWF will
n MUST inject the appropriate native downstream fault indication signal.</t> apply a holdover mechanism to maintain the clock.</t>
<t>Whenever a VPWS comes up, the CE-bound IWF enters the intermediate <t>Whenever the VPWS is not operationally up, the CE-bound NSP functio
state, will start receiving PLE packets and will store them in the jitter buffer n <bcp14>MUST</bcp14> inject the appropriate specific downstream fault-indicatio
. The CE-bound NSP function will continue to inject the appropriate native downs n signal.</t>
tream fault indication signal until a pre-configured number of payload s stored <t>Whenever a VPWS comes up, the CE-bound IWF will enter the intermedi
in the jitter buffer.</t> ate state, will start receiving PLE packets, and will store them in the jitter b
<t>After the pre-configured amount of payload is present in the jitter uffer. The CE-bound NSP function will continue to inject the appropriate specifi
buffer the CE-bound IWF transitions to the normal operation state and the conte c downstream fault-indication signal until a preconfigured number of payload s s
nt of the jitter buffer is streamed out to the CE in accordance with the require tored in the jitter buffer.</t>
d clock. In this state the CE-bound IWF MUST perform egress clock recovery.</t> <t>After the preconfigured amount of payload is present in the jitter
<t>Considerations for choosing the pre-configured amount of payload re buffer, the CE-bound IWF transitions to the normal operation state, and the cont
quired to be present for transitioning into the normal state: ent of the jitter buffer is streamed out to the CE in accordance with the requir
* Typically set to 50% of the de-jitter buffer size to equally allow compensatin ed clock. In this state, the CE-bound IWF <bcp14>MUST</bcp14> perform egress clo
g for increasing and decreasing delay ck recovery.</t>
* Choosing a compromise between the maximum amount of tolerable PDV and delay in <t>Considerations for choosing the preconfigured amount of payload req
troduced to the emulated service</t> uired to be present for transitioning into the normal state:</t>
<t>The recovered clock MUST comply with the jitter and wander requirem <ul>
ents applicable to the type of attachment circuit, specified in:</t>
<li>Typically set to 50% of the de-jitter buffer size to equally allow compensat
ing for increasing and decreasing delay</li>
<li>A compromise between the maximum amount of tolerable PDV and delay introduce
d to the emulated service</li></ul>
<t>The recovered clock <bcp14>MUST</bcp14> comply with the jitter and
wander requirements applicable to the type of attachment circuit, specified in:<
/t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t><xref target="G.825"/>, <xref target="G.783"/> and <xref target ="G.823"/> for SDH</t> <t><xref target="G.825"/>, <xref target="G.783"/>, and <xref targe t="G.823"/> for SDH</t>
</li> </li>
<li> <li>
<t><xref target="GR253"/> and <xref target="GR499"/> for SONET</t> <t><xref target="GR253"/> and <xref target="GR499"/> for SONET</t>
</li> </li>
<li> <li>
<t><xref target="G.8261"/> for synchronous Ethernet</t> <t><xref target="G.8261"/> for synchronous Ethernet</t>
</li> </li>
<li> <li>
<t><xref target="G.8251"/> for OTN</t> <t><xref target="G.8251"/> for OTN</t>
</li> </li>
</ul> </ul>
<t>Whenever the L bit is set in the PLE control word of a received PLE <t>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 downstrea packet, the CE-bound NSP function <bcp14>SHOULD</bcp14> inject the appropriate
m fault indication signal instead of streaming out the payload.</t> specific downstream fault-indication signal instead of streaming out the payload
<t>If the CE-bound IWF detects loss of consecutive packets for a pre-c .</t>
onfigured amount of time (default is 1 millisecond), it enters packet loss (PLOS <t>If the CE-bound IWF detects loss of consecutive packets for a preco
) state and a corresponding defect is declared.</t> nfigured amount of time (default is 1 millisecond), it enters PLOS state and a c
<t>If the CE-bound IWF detects a packet loss ratio (PLR) above a confi orresponding defect is declared.</t>
gurable signal-degrade (SD) threshold for a configurable amount of consecutive 1 <t>If the CE-bound IWF detects a PLR above a configurable SD threshold
-second intervals, it enters the degradation (DEG) state and a corresponding def for a configurable amount of consecutive 1-second intervals, it enters the DEG
ect is declared. The SD-PLR threshold can be defined as percentage with the defa state and a corresponding defect is declared. The SD-PLR threshold can be define
ult being 15% or absolute packet count for finer granularity for higher rate int d as a percentage with the default being 15% or absolute packet count for finer
erfaces. Possible values for consecutive intervals are 2..10 with the default 7. granularity for higher rate interfaces. Possible values for consecutive interval
</t> s are 2..10 with the default 7.</t>
<t>While the PLOS defect is declared the CE-bound NSP function MUST in <t>While the PLOS defect is declared, the CE-bound NSP function <bcp14
ject the appropriate native downstream fault indication signal. If the emulated >MUST</bcp14> inject the appropriate specific downstream fault-indication signal
service does not have a appropriate maintenance signal defined, the CE-bound NSP . If the emulated service does not have an appropriate maintenance signal define
function MAY disable its transmitter instead. Also the PSN-bound IWF SHOULD set d, the CE-bound NSP function <bcp14>MAY</bcp14> disable its transmitter instead.
the R bit in the PLE control word of every packet transmitted.</t> Also, the PSN-bound IWF <bcp14>SHOULD</bcp14> set the R bit in the PLE control
<t>The CE-bound IWF does change from the PLOS to normal state after th word of every packet transmitted.</t>
e pre-configured amount of payload has been received similarly to the transition <t>The CE-bound IWF changes from the PLOS to normal state after the pr
from intermediate to normal state.</t> econfigured amount of payload has been received similar to the transition from i
<t>Whenever the R bit is set in the PLE control word of a received PLE ntermediate to normal state.</t>
packet the PLE performance monitoring statistics SHOULD get updated.</t> <t>Whenever the R bit is set in the PLE control word of a received PLE
packet, the PLE performance monitoring statistics <bcp14>SHOULD</bcp14> get upd
ated.</t>
</section> </section>
</section> </section>
<section anchor="ple-performance-monitoring"> <section anchor="ple-performance-monitoring">
<name>PLE Performance Monitoring</name> <name>PLE Performance Monitoring</name>
<t>Attachment circuit performance monitoring SHOULD be provided by the N <t>Attachment circuit performance monitoring <bcp14>SHOULD</bcp14> be pr
SP. The performance monitors are service specific, documented in related specifi ovided by the NSP. The performance monitors are service specific, documented in
cations and beyond the scope of this document.</t> related specifications, and beyond the scope of this document.</t>
<t>The PLE IWF SHOULD provide functions to monitor the network performan <t>The PLE IWF <bcp14>SHOULD</bcp14> provide functions to monitor the ne
ce to be inline with expectations of transport network operators.</t> twork performance to be inline with expectations of transport network operators.
</t>
<t>The near-end performance monitors defined for PLE are as follows:</t> <t>The near-end performance monitors defined for PLE are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>ES-PLE : PLE Errored Seconds</t> <t>ES-PLE : PLE Errored Seconds</t>
</li> </li>
<li> <li>
<t>SES-PLE : PLE Severely Errored Seconds</t> <t>SES-PLE : PLE Severely Errored Seconds</t>
</li> </li>
<li> <li>
<t>UAS-PLE : PLE Unavailable Seconds</t> <t>UAS-PLE : PLE Unavailable Seconds</t>
</li> </li>
</ul> </ul>
<t>Each second with at least one packet lost or a PLOS/DEG defect SHALL <t>Each second with at least one packet lost or a PLOS or DEG defect <bc
be counted as ES-PLE. Each second with a PLR greater than 15% or a PLOS/DEG defe p14>SHALL</bcp14> be counted as an ES-PLE. Each second with a PLR greater than 1
ct SHALL be counted as SES-PLE.</t> 5% or a PLOS or DEG defect <bcp14>SHALL</bcp14> be counted as an SES-PLE.</t>
<t>UAS-PLE SHALL be counted after a configurable number of consecutive S <t>UAS-PLE <bcp14>SHALL</bcp14> be counted after a configurable number o
ES-PLE have been observed, and no longer counted after a configurable number of f consecutive SES-PLEs have been observed, and no longer counted after a configu
consecutive seconds without SES-PLE have been observed. Default value for each i rable number of consecutive seconds without an SES-PLE have been observed. The d
s 10 seconds.</t> efault value for each is 10 seconds.</t>
<t>Once unavailability is detected, ES and SES counts SHALL be inhibited <t>Once unavailability is detected, ES-PLE and SES-PLE counts <bcp14>SHA
up to the point where the unavailability was started. Once unavailability is re LL</bcp14> be inhibited
moved, ES and SES that occurred along the clearing period SHALL be added to the up to the point where the unavailability was started. Once
ES and SES counts.</t> unavailability is removed, ES-PLE and SES-PLE that occurred along the
<t>A PLE far-end performance monitor is providing insight into the CE-bo clearing period <bcp14>SHALL</bcp14> be added to the ES-PLE and SES-PLE count
und IWF at the far end of the PSN. The statistics are based on the PLE-RDI indic s.</t>
ation carried in the PLE control word via the R bit.</t> <t>A PLE far-end performance monitor provides insight into the CE-bound
<t>The PLE VPWS performance monitors are derived from the definitions in IWF at the far end of the PSN. The statistics are based on the PLE-RDI indicatio
accordance with <xref target="G.826"/></t> n carried in the PLE control word via the R bit.</t>
<t>Performance monitoring data MUST be provided by the management interf <t>The PLE VPWS performance monitors are derived from the definitions in
ace and SHOULD be accordance with <xref target="G.826"/>.</t>
provided by a YANG model. The YANG model specification is out of scope for this <t>Performance monitoring data <bcp14>MUST</bcp14> be provided by the ma
document.</t> nagement interface and <bcp14>SHOULD</bcp14> be
provided by a YANG data model. The YANG data model specification is out of scope
for this document.</t>
</section> </section>
<section anchor="ple-fault-management"> <section anchor="ple-fault-management">
<name>PLE Fault Management</name> <name>PLE Fault Management</name>
<t>Attachment circuit faults applicable to PLE are detected by the NSP, <t>Attachment circuit faults applicable to PLE are detected by the NSP,
are service specific and are documented in relevant section of <xref target="emu are service specific, and are documented in <xref target="emulated-services"/>.<
lated-services"/>.</t> /t>
<t>The two PLE faults, PLOS and DEG are detected by the IWF.</t> <t>The two PLE faults, PLOS and DEG, are detected by the IWF.</t>
<t>Faults MUST be time stamped as they are declared and cleared and faul <t>Faults <bcp14>MUST</bcp14> be timestamped as they are declared and cl
t related information MUST be provided by the management interface and SHOULD be eared; fault-related information <bcp14>MUST</bcp14> be provided by the manageme
provided by a YANG model. The YANG model specification is out of scope for this nt interface and <bcp14>SHOULD</bcp14> be provided by a YANG data model. The YAN
document.</t> G data model specification is out of scope for this document.</t>
</section> </section>
</section> </section>
<section anchor="qos-and-congestion-control"> <section anchor="qos-and-congestion-control">
<name>QoS and Congestion Control</name> <name>QoS and Congestion Control</name>
<t>The PSN carrying PLE VPWS may be subject to congestion. Congestion cons iderations for PWs are described in <xref section="6.5" sectionFormat="of" targe t="RFC3985"/>.</t> <t>The PSN carrying PLE VPWS may be subject to congestion. Congestion cons iderations for PWs are described in <xref section="6.5" sectionFormat="of" targe t="RFC3985"/>.</t>
<t>PLE VPWS represent inelastic constant bit-rate (CBR) flows that cannot <t>PLE VPWS represent inelastic CBR flows that cannot respond to congestio
respond to congestion in a TCP-friendly manner as described in <xref target="RFC n in a TCP-friendly manner (as described in <xref target="RFC2914"/>) and are se
2914"/> and are sensitive to jitter, packet loss and packets received out of ord nsitive to jitter, packet loss, and packets received out of order.</t>
er.</t>
<t>The PSN providing connectivity between PE devices of a PLE VPWS has to <t>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 o ensure low jitter and low loss. The exact mechanisms used are beyond the scope o
f this document and may evolve over time. Possible options, but not exhaustively f this document and may evolve over time. Possible options, but not exhaustively
, are a Diffserv-enabled <xref target="RFC2475"/> PSN with a per domain behavior , are as follows:</t>
<xref target="RFC3086"/> supporting Expedited Forwarding <xref target="RFC3246" <ul>
/>. Traffic-engineered paths through the PSN with bandwidth reservation and admi <li>a Diffserv-enabled <xref target="RFC2475"/> PSN with a per-domain beh
ssion control applied. Or capacity over-provisioning.</t> avior (see <xref target="RFC3086"/>) supporting Expedited Forwarding (see <xref
target="RFC3246"/>),</li>
<li>traffic-engineered paths through the PSN with bandwidth reservation a
nd admission control applied, or</li>
<li>capacity over-provisioning.</li></ul>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>As PLE is leveraging VPWS as transport mechanism, the security consider ations described <xref target="RFC3985"/> are applicable.</t> <t>As PLE is leveraging VPWS as transport mechanism, the security consider ations described in <xref target="RFC3985"/> are applicable.</t>
<t>PLE does not enhance or detract from the security performance of the un derlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and a uthentication whenever required.</t> <t>PLE does not enhance or detract from the security performance of the un derlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and a uthentication whenever required.</t>
<t>The PSN (MPLS or SRv6) is assumed to be trusted and secure. Attackers w ho manage to send spoofed packets into the PSN could easily disrupt the PLE serv ice. This MUST be prevented by following best practices for the isolation of the PSN. These protections are described in the considerations in <xref section="3. 4" sectionFormat="of" target="RFC4381"/>, <xref section="4.2" sectionFormat="of" target="RFC5920"/> in <xref section="8" sectionFormat="of" target="RFC8402"/> a nd <xref section="9.3" sectionFormat="of" target="RFC9252"/>.</t> <t>The PSN (MPLS or SRv6) is assumed to be trusted and secure. Attackers w ho manage to send spoofed packets into the PSN could easily disrupt the PLE serv ice. This <bcp14>MUST</bcp14> be prevented by following best practices for the i solation of the PSN. These protections are described in <xref section="3.4" sect ionFormat="of" target="RFC4381"/>, <xref section="4.2" sectionFormat="of" target ="RFC5920"/>, <xref section="8" sectionFormat="of" target="RFC8402"/>, and <xre f section="9.3" sectionFormat="of" target="RFC9252"/>.</t>
<t>PLE PWs share susceptibility to a number of pseudowire-layer attacks an d will use whatever mechanisms for confidentiality, integrity, and authenticatio n that are developed for general PWs. These methods are beyond the scope of this document.</t> <t>PLE PWs share susceptibility to a number of pseudowire-layer attacks an d will use whatever mechanisms for confidentiality, integrity, and authenticatio n that are developed for general PWs. These methods are beyond the scope of this document.</t>
<t>Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks more difficult.</t> <t>Random initialization of sequence numbers, in both the control word and the RTP header, makes known-plaintext attacks more difficult.</t>
<t>Misconnection detection using the SSRC and/or PT field of the RTP heade <t>Misconnection detection using the SSRC and/or PT field of the RTP heade
r can increase the resilience to misconfiguration and some types of denial-of-se r can increase the resilience to misconfiguration and some types of denial-of-se
rvice (DoS) attacks. Randomly chosen expected values do decrease the chance of a rvice (DoS) attacks. Randomly chosen expected values decrease the chance of a sp
spoofing attack being successful.</t> oofing attack being successful.</t>
<t>A data plane attack may force PLE packets to be dropped, re-ordered or <t>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 delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either
degradation or service disruption. Considerations outlined in <xref target="RFC degradation or service disruption. Considerations outlined in <xref target="RFC
9055"/> are a good reference.</t> 9055"/> are a good reference.</t>
<t>Clock synchronization leveraging PTP is sensitive to Packet Delay Varia
tion (PDV) and vulnerable to various threads and attack vectors. Considerations <t>Clock synchronization leveraging PTP is sensitive to PDV and vulnerable
outlined in <xref target="RFC7384"/> should be taken into account.</t> to various threats and attack vectors. Considerations outlined in <xref target=
"RFC7384"/> should be taken into account.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="bit-stream-next-header-type"> <section anchor="bit-stream-next-header-type">
<name>Bit-stream Next Header Type</name> <name>Bit-Stream Next Header Type</name>
<t>This document introduces a new value to be used in the next header fi <t>This document introduces a new value to be used in the next header fi
eld of an IPv6 header or any extension header indicating that the payload is a e eld of an IPv6 header or any extension header indicating that the payload is an
mulated bit-stream. IANA is requested to assign the following from the "Assigned emulated bit-stream. IANA has assigned the following from the "Assigned Internet
Internet Protocol Numbers" registry <xref target="IANA-Proto"/>.</t> Protocol Numbers" registry <xref target="IANA-Proto"/>.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Decimal</th> <th align="left">Decimal</th>
<th align="left">Keyword</th> <th align="left">Keyword</th>
<th align="left">Protocol</th> <th align="left">Protocol</th>
<th align="left">IPv6 Extension Header</th> <th align="left">IPv6 Extension Header</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBA1</td> <td align="left">147</td>
<td align="left">BIT-EMU</td> <td align="left">BIT-EMU</td>
<td align="left">Bit-stream Emulation</td> <td align="left">Bit-stream Emulation</td>
<td align="left">Y</td> <td align="left">Y</td>
<td align="left">this document</td> <td align="left">This document</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="srv6-endpoint-behaviors"> <section anchor="srv6-endpoint-behaviors">
<name>SRv6 Endpoint Behaviors</name> <name>SRv6 Endpoint Behaviors</name>
<t>This document introduces three new SRv6 Endpoint behaviors. IANA is r equested to assign identifier values in the "SRv6 Endpoint Behaviors" sub-regist ry under "Segment Routing" registry <xref target="IANA-SRv6-End"/>.</t> <t>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 <xref target="IANA-SRv6-End"/>.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Hex</th> <th align="left">Hex</th>
<th align="left">Endpoint Behavior</th> <th align="left">Endpoint Behavior</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">158</td> <td align="left">158</td>
<td align="left">0x009E</td> <td align="left">0x009E</td>
<td align="left">End.DX1</td> <td align="left">End.DX1</td>
<td align="left">this document</td> <td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">159</td> <td align="left">159</td>
<td align="left">0x009F</td> <td align="left">0x009F</td>
<td align="left">End.DX1 with NEXT-CSID</td> <td align="left">End.DX1 with NEXT-CSID</td>
<td align="left">this document</td> <td align="left">This document</td>
</tr> </tr>
<tr> <tr>
<td align="left">160</td> <td align="left">160</td>
<td align="left">0x00A0</td> <td align="left">0x00A0</td>
<td align="left">End.DX1 with REPLACE-CSID</td> <td align="left">End.DX1 with REPLACE-CSID</td>
<td align="left">this document</td> <td align="left">This document</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="acknowledgements">
<name>Acknowledgements</name>
<t>The authors would like to thank Alexander Vainshtein, Yaakov Stein, Eri
k van Veelen, Faisal Dada, Giles Heron, Luca Della Chiesa and Ashwin Gumaste for
their early contributions, review, comments and suggestions.</t>
<t>Special thank you to</t>
<ul spacing="normal">
<li>
<t>Carlos Pignataro and Nagendra Kumar Nainar for giving the authors n
ew to IETF guidance on how to get started</t>
</li>
<li>
<t>Stewart Bryant for being our shepherd</t>
</li>
<li>
<t>Tal Mizahi, Joel Halpern, Christian Huitema, Tony Li, Tommy Pauly f
or their reviews and suggestions during last call</t>
</li>
<li>
<t>Andrew Malis and Gunter van de Velde for their guidance through the
process</t>
</li>
</ul>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.schmutzer-bess-bitstream-vpws-signalling" to="
EVPN-VPWS"/>
<displayreference target="I-D.schmutzer-pals-ple-signaling" to="LDP-PLE"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC3985"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 985.xml"/>
<title>Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture</title <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
> 550.xml"/>
<author fullname="S. Bryant" initials="S." role="editor" surname="Br <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
yant"/> 551.xml"/>
<author fullname="P. Pate" initials="P." role="editor" surname="Pate <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
"/> 986.xml"/>
<date month="March" year="2005"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<abstract> 252.xml"/>
<t>This document describes an architecture for Pseudo Wire Emulati <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
on Edge-to-Edge (PWE3). It discusses the emulation of services such as Frame Rel 402.xml"/>
ay, ATM, Ethernet, TDM, and SONET/SDH over packet switched networks (PSNs) using
IP or MPLS. It presents the architectural framework for pseudo wires (PWs), def <reference anchor="IEEE802.3" target="https://ieeexplore.ieee.org/docume
ines terminology, and specifies the various protocol elements and their function nt/9844436">
s. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3985"/>
<seriesInfo name="DOI" value="10.17487/RFC3985"/>
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="S. Casner" initials="S." surname="Casner"/>
<author fullname="R. Frederick" initials="R." surname="Frederick"/>
<author fullname="V. Jacobson" initials="V." surname="Jacobson"/>
<date month="July" year="2003"/>
<abstract>
<t>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 multi
cast or unicast network services. RTP does not address resource reservation and
does not guarantee quality-of- service for real-time services. The data transpor
t is augmented by a control protocol (RTCP) to allow monitoring of the data deli
very in a manner scalable to large multicast networks, and to provide minimal co
ntrol and identification functionality. RTP and RTCP are designed to be independ
ent of the underlying transport and network layers. The protocol supports the us
e of RTP-level translators and mixers. Most of the text in this memorandum is id
entical to RFC 1889 which it obsoletes. There are no changes in the packet forma
ts on the wire, only changes to the rules and algorithms governing how the proto
col is used. The biggest change is an enhancement to the scalable timer algorith
m for calculating when to send RTCP packets in order to minimize transmission in
excess of the intended rate when many participants join a session simultaneousl
y. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC3551">
<front>
<title>RTP Profile for Audio and Video Conferences with Minimal Cont
rol</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne
"/>
<author fullname="S. Casner" initials="S." surname="Casner"/>
<date month="July" year="2003"/>
<abstract>
<t>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 minima
l control. It provides interpretations of generic fields within the RTP specific
ation suitable for audio and video conferences. In particular, this document def
ines a set of default mappings from payload type numbers to encodings. This docu
ment also describes how audio and video data may be carried within RTP. It defin
es a set of standard encodings and their names when used within RTP. The descrip
tions 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 impl
ementations were not found. The additions to RFC 1890 codify existing practice i
n the use of payload formats under this profile and include new payload formats
defined since RFC 1890 was published. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="65"/>
<seriesInfo name="RFC" value="3551"/>
<seriesInfo name="DOI" value="10.17487/RFC3551"/>
</reference>
<reference anchor="RFC8986">
<front>
<title>Segment Routing over IPv6 (SRv6) Network Programming</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="P. Camarillo" initials="P." role="editor" surname=
"Camarillo"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="Z. Li" initials="Z." surname="Li"/>
<date month="February" year="2021"/>
<abstract>
<t>The Segment Routing over IPv6 (SRv6) Network Programming framew
ork enables a network operator or an application to specify a packet processing
program by encoding a sequence of instructions in the IPv6 packet header.</t>
<t>Each instruction is implemented on one or several nodes in the
network and identified by an SRv6 Segment Identifier in the packet.</t>
<t>This document defines the SRv6 Network Programming concept and
specifies the base set of SRv6 behaviors that enables the creation of interopera
ble overlays with underlay optimization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8986"/>
<seriesInfo name="DOI" value="10.17487/RFC8986"/>
</reference>
<reference anchor="RFC9252">
<front>
<title>BGP Overlay Services Based on Segment Routing over IPv6 (SRv6
)</title>
<author fullname="G. Dawra" initials="G." role="editor" surname="Daw
ra"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname
="Talaulikar"/>
<author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
<author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
<date month="July" year="2022"/>
<abstract>
<t>This document defines procedures and messages for SRv6-based BG
P services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVP
N), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (V
PNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9252"/>
<seriesInfo name="DOI" value="10.17487/RFC9252"/>
</reference>
<reference anchor="RFC8402">
<front>
<title>Segment Routing Architecture</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="S. Previdi" initials="S." role="editor" surname="P
revidi"/>
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
<author fullname="B. Decraene" initials="B." surname="Decraene"/>
<author fullname="S. Litkowski" initials="S." surname="Litkowski"/>
<author fullname="R. Shakir" initials="R." surname="Shakir"/>
<date month="July" year="2018"/>
<abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A n
ode 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 provi
des a mechanism that allows a flow to be restricted to a specific topological pa
th, while maintaining per-flow state only at the ingress node(s) to the SR domai
n.</t>
<t>SR can be directly applied to the MPLS architecture with no cha
nge to the forwarding plane. A segment is encoded as an MPLS label. An ordered l
ist of segments is encoded as a stack of labels. The segment to process is on th
e top of the stack. Upon completion of a segment, the related label is popped fr
om the stack.</t>
<t>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 segm
ents 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 n
ext active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8402"/>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
</reference>
<reference anchor="IEEE802.3" target="https://standards.ieee.org/ieee/80
2.3/10422/">
<front> <front>
<title>IEEE Standard for Ethernet</title> <title>IEEE Standard for Ethernet</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date year="2022" month="May"/> <date year="2022" month="July"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.3-2022"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9844436"/>
</reference> </reference>
<reference anchor="G.707" target="https://www.itu.int/rec/T-REC-G.707"> <reference anchor="G.707" target="https://www.itu.int/rec/T-REC-G.707">
<front> <front>
<title>Network node interface for the synchronous digital hierarchy (SDH)</title> <title>Network node interface for the synchronous digital hierarchy (SDH)</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2007" month="January"/> <date year="2007" month="January"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.707"/>
</reference> </reference>
<reference anchor="G.709" target="https://www.itu.int/rec/T-REC-G.709"> <reference anchor="G.709" target="https://www.itu.int/rec/T-REC-G.709">
<front> <front>
<title>Interfaces for the optical transport network</title> <title>Interfaces for the optical transport network</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2020" month="June"/> <date year="2020" month="June"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.709"/>
</reference> </reference>
<reference anchor="G.823" target="https://www.itu.int/rec/T-REC-G.823"> <reference anchor="G.823" target="https://www.itu.int/rec/T-REC-G.823">
<front> <front>
<title>The control of jitter and wander within digital networks whic h are based on the 2048 kbit/s hierarchy</title> <title>The control of jitter and wander within digital networks whic h are based on the 2048 kbit/s hierarchy</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2000" month="March"/> <date year="2000" month="March"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.823"/>
</reference> </reference>
<reference anchor="G.825" target="https://www.itu.int/rec/T-REC-G.825"> <reference anchor="G.825" target="https://www.itu.int/rec/T-REC-G.825">
<front> <front>
<title>The control of jitter and wander within digital networks whic h are based on the synchronous digital hierarchy (SDH)</title> <title>The control of jitter and wander within digital networks whic h are based on the synchronous digital hierarchy (SDH)</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz <organization>ITU-T</organization>
ation>
</author>
<date year="2000" month="March"/>
</front>
</reference>
<reference anchor="G.824" target="https://www.itu.int/rec/T-REC-G.824">
<front>
<title>The control of jitter and wander within digital networks whic
h are based on the 1544 kbits hierarchy</title>
<author>
<organization>International Telecommunication Union (ITU)</organiz
ation>
</author> </author>
<date year="2000" month="March"/> <date year="2000" month="March"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.825"/>
</reference> </reference>
<reference anchor="G.783" target="https://www.itu.int/rec/T-REC-G.783"> <reference anchor="G.783" target="https://www.itu.int/rec/T-REC-G.783">
<front> <front>
<title>Characteristics of synchronous digital hierarchy (SDH) equipm ent functional blocks</title> <title>Characteristics of synchronous digital hierarchy (SDH) equipm ent functional blocks</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2006" month="March"/> <date year="2006" month="March"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.783"/>
</reference> </reference>
<reference anchor="G.8251" target="https://www.itu.int/rec/T-REC-G.8251" > <reference anchor="G.8251" target="https://www.itu.int/rec/T-REC-G.8251" >
<front> <front>
<title>The control of jitter and wander within the optical transport network (OTN)</title> <title>The control of jitter and wander within the optical transport network (OTN)</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2022" month="November"/> <date year="2022" month="November"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.8251"/>
</reference> </reference>
<reference anchor="G.8261" target="https://www.itu.int/rec/T-REC-G.8261" > <reference anchor="G.8261" target="https://www.itu.int/rec/T-REC-G.8261" >
<front> <front>
<title>Timing and synchronization aspects in packet networks</title> <title>Timing and synchronization aspects in packet networks</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2019" month="August"/> <date year="2019" month="August"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.8261"/>
</reference> </reference>
<reference anchor="G.8262" target="https://www.itu.int/rec/T-REC-G.8262" > <reference anchor="G.8262" target="https://www.itu.int/rec/T-REC-G.8262" >
<front> <front>
<title>Timing characteristics of synchronous equipment slave clock</ title> <title>Timing characteristics of synchronous equipment clocks</title >
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2018" month="November"/> <date year="2024" month="October"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.8262"/>
</reference> </reference>
<reference anchor="G.8261.1" target="https://www.itu.int/rec/T-REC-G.826 1.1"> <reference anchor="G.8261.1" target="https://www.itu.int/rec/T-REC-G.826 1.1">
<front> <front>
<title>Packet delay variation network limits applicable to packet-ba sed methods (Frequency synchronization)</title> <title>Packet delay variation network limits applicable to packet-ba sed methods (Frequency synchronization)</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2012" month="February"/> <date year="2012" month="February"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.8261.1"/>
</reference> </reference>
<reference anchor="G.8265.1" target="https://www.itu.int/rec/T-REC-G.826 5.1"> <reference anchor="G.8265.1" target="https://www.itu.int/rec/T-REC-G.826 5.1">
<front> <front>
<title>Precision time protocol telecom profile for frequency synchro nization</title> <title>Precision time protocol telecom profile for frequency synchro nization</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2022" month="November"/> <date year="2022" month="November"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.8265.1"/>
</reference> </reference>
<reference anchor="GR253" target="https://telecom-info.njdepot.ericsson. net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&amp;DOCUMENT=GR-253"> <reference anchor="GR253" target="https://telecom-info.njdepot.ericsson. net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&amp;DOCUMENT=GR-253">
<front> <front>
<title>SONET Transport Systems - Common Generic Criteria</title> <title>Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria</title>
<author> <author>
<organization>Telcordia</organization> <organization>Telcordia</organization>
</author> </author>
<date year="2009" month="October"/> <date year="2009" month="October"/>
</front> </front>
<refcontent>GR-253</refcontent>
</reference> </reference>
<reference anchor="GR499" target="https://telecom-info.njdepot.ericsson. net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&amp;DOCUMENT=GR-499"> <reference anchor="GR499" target="https://telecom-info.njdepot.ericsson. net/site-cgi/ido/docs.cgi?ID=2111701336SEARCH&amp;DOCUMENT=GR-499">
<front> <front>
<title>Transport Systems Generic Requirements (TSGR) - Common Requir ements</title> <title>Transport Systems Generic Requirements (TSGR) - Common Requir ements</title>
<author> <author>
<organization>Telcordia</organization> <organization>Telcordia</organization>
</author> </author>
<date year="2009" month="November"/> <date year="2009" month="November"/>
</front> </front>
<refcontent>GR-499</refcontent>
</reference> </reference>
<reference anchor="IANA-Proto" target="https://www.iana.org/assignments/
protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1"> <reference anchor="IANA-Proto" target="https://www.iana.org/assignments/
protocol-numbers">
<front> <front>
<title>IANA "Assigned Internet Protocol Numbers" sub-registry</title > <title>Assigned Internet Protocol Numbers</title>
<author> <author>
<organization>IETF</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="IANA-SRv6-End" target="https://www.iana.org/assignmen
ts/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors"> <reference anchor="IANA-SRv6-End" target="https://www.iana.org/assignmen
ts/segment-routing">
<front> <front>
<title>IANA "SRv6 Endpoint Behaviors" sub-registry</title> <title>SRv6 Endpoint Behaviors</title>
<author> <author>
<organization>IETF</organization> <organization>IANA</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="I-D.draft-ietf-spring-srv6-srh-compression">
<front>
<title>Compressed SRv6 Segment List Encoding (CSID)</title>
<author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
<organization>China Mobile</organization>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils
">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
</author>
<author fullname="Francois Clad" initials="F." surname="Clad">
<organization>Cisco Systems, Inc.</organization>
</author>
<date day="6" month="February" year="2025"/>
<abstract>
<t> Segment Routing over IPv6 (SRv6) is the instantiation of Seg
ment
Routing (SR) on the IPv6 dataplane. 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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
the Segment Routing Header (SRH) to be either an IPv6 address, as 119.xml"/>
specified in RFC 8754, or a REPLACE-CSID container in packed format, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
as specified in this document. 174.xml"/>
<!-- [RFC9800] draft-ietf-spring-srv6-srh-compression-23 companion doc.
-->
<reference anchor="RFC9800" target="https://www.rfc-editor.org/info/rfc9800">
<front>
<title>Compressed SRv6 Segment List Encoding (CSID)</title>
<author initials="W." surname="Cheng" fullname="Weiqiang Cheng" role="edit
or">
<organization>China Mobile</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems, Inc.</organization>
</author>
<author initials="Z." surname="Li" fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
</author>
<author initials="F." surname="Clad" fullname="Francois Clad" role="editor
">
<organization>Cisco Systems, Inc.</organization>
</author>
<date month='June' year='2025'/>
</front>
<seriesInfo name="RFC" value="9800"/>
<seriesInfo name="DOI" value="10.17487/RFC9800"/>
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-spring-srv6-srh-co
mpression-23"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4197"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 197.xml"/>
<title>Requirements for Edge-to-Edge Emulation of Time Division Mult <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
iplexed (TDM) Circuits over Packet Switching Networks</title> 381.xml"/>
<author fullname="M. Riegel" initials="M." role="editor" surname="Ri <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
egel"/> 920.xml"/>
<date month="October" year="2005"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<abstract> 385.xml"/>
<t>This document defines the specific requirements for edge-to-edg
e emulation of circuits carrying Time Division Multiplexed (TDM) digital signals
of the Plesiochronous Digital Hierarchy as well as the Synchronous Optical NETw
ork/Synchronous Digital Hierarchy over packet-switched networks. It is aligned t
o the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It make
s references to the generic requirements for PWE3 where applicable and complemen
ts them by defining requirements originating from specifics of TDM circuits. Thi
s memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4197"/>
<seriesInfo name="DOI" value="10.17487/RFC4197"/>
</reference>
<reference anchor="RFC4381">
<front>
<title>Analysis of the Security of BGP/MPLS IP Virtual Private Netwo
rks (VPNs)</title>
<author fullname="M. Behringer" initials="M." surname="Behringer"/>
<date month="February" year="2006"/>
<abstract>
<t>This document analyses the security of the BGP/MPLS IP virtual
private network (VPN) architecture that is described in RFC 4364, for the benefi
t of service providers and VPN users.</t>
<t>The analysis shows that BGP/MPLS IP VPN networks can be as secu
re as traditional layer-2 VPN services using Asynchronous Transfer Mode (ATM) or
Frame Relay. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4381"/>
<seriesInfo name="DOI" value="10.17487/RFC4381"/>
</reference>
<reference anchor="RFC5920">
<front>
<title>Security Framework for MPLS and GMPLS Networks</title>
<author fullname="L. Fang" initials="L." role="editor" surname="Fang
"/>
<date month="July" year="2010"/>
<abstract>
<t>This document provides a security framework for Multiprotocol L
abel Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Netw
orks. This document addresses the security aspects that are relevant in the cont
ext of MPLS and GMPLS. It describes the security threats, the related defensive
techniques, and the mechanisms for detection and reporting. This document emphas
izes RSVP-TE and LDP security considerations, as well as inter-AS and inter-prov
ider security considerations for building and maintaining MPLS and GMPLS network
s across different domains or different Service Providers. This document is not
an Internet Standards Track specification; it is published for informational pur
poses.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5920"/>
<seriesInfo name="DOI" value="10.17487/RFC5920"/>
</reference>
<reference anchor="RFC4385">
<front>
<title>Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use
over an MPLS PSN</title>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<author fullname="G. Swallow" initials="G." surname="Swallow"/>
<author fullname="L. Martini" initials="L." surname="Martini"/>
<author fullname="D. McPherson" initials="D." surname="McPherson"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes the preferred design of a Pseudowire Em
ulation 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 fiel
ds is chosen so that an MPLS Label Switching Router performing MPLS payload insp
ection will not confuse a PWE3 payload with an IP payload. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4385"/>
<seriesInfo name="DOI" value="10.17487/RFC4385"/>
</reference>
<reference anchor="T11" target="https://www.incits.org/committees/t11"> <reference anchor="T11" target="https://www.incits.org/committees/t11">
<front> <front>
<title>T11 - Fibre Channel</title> <title>T11 - Fibre Channel</title>
<author> <author>
<organization>INCITS</organization> <organization>INCITS</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="FC-PI-2" target="https://webstore.ansi.org/standards/
incits/incits4042006"> <reference anchor="FC-PI-2" target="https://webstore.ansi.org/standards/
incits/incits4042006s2016">
<front> <front>
<title>Information Technology - Fibre Channel Physical Interfaces - 2 (FC-PI-2)</title> <title>Information Technology - Fibre Channel Physical Interfaces - 2 (FC-PI-2)</title>
<author> <author>
<organization>INCITS</organization> <organization>INCITS</organization>
</author> </author>
<date year="2006"/> <date year="2016"/>
</front> </front>
<seriesInfo name="INCITS" value="404-2006 (S2016)"/>
</reference> </reference>
<reference anchor="FC-PI-5" target="https://webstore.ansi.org/standards/
incits/incits4792011"> <reference anchor="FC-PI-5" target="https://webstore.ansi.org/standards/
incits/incits4792011s2021">
<front> <front>
<title>Information Technology - Fibre Channel - Physical Interface-5 (FC-PI-5)</title> <title>Information Technology - Fibre Channel - Physical Interface-5 (FC-PI-5)</title>
<author> <author>
<organization>INCITS</organization> <organization>INCITS</organization>
</author> </author>
<date year="2011"/> <date year="2021"/>
</front> </front>
<seriesInfo name="INCITS" value="479-2011 (S2021)"/>
</reference> </reference>
<reference anchor="FC-PI-5am1" target="https://webstore.ansi.org/standar
ds/incits/incits4792011am12016"> <reference anchor="FC-PI-5am1" target="https://webstore.ansi.org/standar
ds/incits/incits4792011am2016r2021">
<front> <front>
<title>Information Technology - Fibre Channel - Physical Interface - 5/Amendment 1 (FC-PI-5/AM1)</title> <title>Information Technology - Fibre Channel - Physical Interface - 5/Amendment 1 (FC-PI-5/AM1)</title>
<author> <author>
<organization>INCITS</organization> <organization>INCITS</organization>
</author> </author>
<date year="2016"/> <date year="2021"/>
</front> </front>
<seriesInfo name="INCITS" value="479-2011/AM1-2016 (R2021)"/>
</reference> </reference>
<reference anchor="FC-PI-6" target="https://webstore.ansi.org/standards/
incits/incits5122015"> <reference anchor="FC-PI-6" target="https://webstore.ansi.org/standards/
incits/incits5122015r2020">
<front> <front>
<title>Information Technology - Fibre Channel - Physical Interface - 6 (FC-PI-6)</title> <title>Information Technology - Fibre Channel - Physical Interface - 6 (FC-PI-6)</title>
<author> <author>
<organization>INCITS</organization> <organization>INCITS</organization>
</author> </author>
<date year="2015"/> <date year="2020"/>
</front> </front>
<seriesInfo name="INCITS" value="512-2015 (R2020)"/>
</reference> </reference>
<reference anchor="FC-PI-6P" target="https://webstore.ansi.org/standards
/incits/incits5332016"> <reference anchor="FC-PI-6P" target="https://webstore.ansi.org/standards
/incits/incits5332016r2021">
<front> <front>
<title>Information Technology - Fibre Channel - Physical Interface - 6P (FC-PI-6P)</title> <title>Information Technology - Fibre Channel - Physical Interface - 6P (FC-PI-6P)</title>
<author> <author>
<organization>INCITS</organization> <organization>INCITS</organization>
</author> </author>
<date year="2016"/> <date year="2021"/>
</front> </front>
<seriesInfo name="INCITS" value="533-2016 (R2021)"/>
</reference> </reference>
<reference anchor="FC-PI-7" target="https://webstore.ansi.org/standards/
iso/isoiec141651472021"> <reference anchor="FC-PI-7" target="https://www.iso.org/standard/80933.h
tml">
<front> <front>
<title>Information Technology – Fibre Channel - Physical Interfaces - 7 (FC-PI-7)</title> <title>Information technology – Fibre channel - Part 147: Physical i nterfaces - 7 (FC-PI-7)</title>
<author> <author>
<organization>INCITS</organization> <organization>ISO/IEC</organization>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="14165-147:2021"/>
</reference> </reference>
<reference anchor="G.826" target="https://www.itu.int/rec/T-REC-G.826"> <reference anchor="G.826" target="https://www.itu.int/rec/T-REC-G.826">
<front> <front>
<title>End-to-end error performance parameters and objectives for in ternational, constant bit-rate digital paths and connections</title> <title>End-to-end error performance parameters and objectives for in ternational, constant bit-rate digital paths and connections</title>
<author> <author>
<organization>International Telecommunication Union (ITU)</organiz ation> <organization>ITU-T</organization>
</author> </author>
<date year="2002" month="December"/> <date year="2002" month="December"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="G.826"/>
</reference> </reference>
<reference anchor="ATIS-0900105.09.2013" target="https://webstore.ansi.o rg/standards/atis/atis0900105092013s2023"> <reference anchor="ATIS-0900105.09.2013" target="https://webstore.ansi.o rg/standards/atis/atis0900105092013s2023">
<front> <front>
<title>Synchronous Optical Network (SONET) - Network Element Timing and Synchronization</title> <title>Synchronous Optical Network (SONET) - Network Element Timing and Synchronization</title>
<author> <author>
<organization>ATIS</organization> <organization>ATIS</organization>
</author> </author>
<date year="2013"/> <date year="2023"/>
</front>
</reference>
<reference anchor="RFC4553">
<front>
<title>Structure-Agnostic Time Division Multiplexing (TDM) over Pack
et (SAToP)</title>
<author fullname="A. Vainshtein" initials="A." role="editor" surname
="Vainshtein"/>
<author fullname="YJ. Stein" initials="YJ." role="editor" surname="S
tein"/>
<date month="June" year="2006"/>
<abstract>
<t>This document describes a pseudowire encapsulation for Time Div
ision Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any struct
ure that may be imposed on these streams, in particular the structure imposed by
the standard TDM framing. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4553"/>
<seriesInfo name="DOI" value="10.17487/RFC4553"/>
</reference>
<reference anchor="RFC4906">
<front>
<title>Transport of Layer 2 Frames Over MPLS</title>
<author fullname="L. Martini" initials="L." role="editor" surname="M
artini"/>
<author fullname="E. Rosen" initials="E." role="editor" surname="Ros
en"/>
<author fullname="N. El-Aawar" initials="N." role="editor" surname="
El-Aawar"/>
<date month="June" year="2007"/>
<abstract>
<t>This document describes methods for transporting the Protocol D
ata Units (PDUs) of layer 2 protocols such as Frame Relay, Asynchronous Transfer
Mode (ATM) Adaption Layer 5 (AAL5), and Ethernet, and for providing a Synchroni
zed Optical Network (SONET) circuit emulation service across an MPLS network. Th
is document describes the so-called "draft-martini" protocol, which has since be
en superseded by the Pseudowire Emulation Edge to Edge Working Group specificati
ons described in RFC 4447 and related documents. This memo defines a Historic Do
cument for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4906"/>
<seriesInfo name="DOI" value="10.17487/RFC4906"/>
</reference>
<reference anchor="RFC4448">
<front>
<title>Encapsulation Methods for Transport of Ethernet over MPLS Net
works</title>
<author fullname="L. Martini" initials="L." role="editor" surname="M
artini"/>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="N. El-Aawar" initials="N." surname="El-Aawar"/>
<author fullname="G. Heron" initials="G." surname="Heron"/>
<date month="April" year="2006"/>
<abstract>
<t>An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Pro
tocol Data Units (PDUs) over an MPLS network. This enables service providers to
offer "emulated" Ethernet services over existing MPLS networks. This document sp
ecifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also sp
ecifies the procedures for using a PW to provide a "point-to-point Ethernet" ser
vice. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4448"/>
<seriesInfo name="DOI" value="10.17487/RFC4448"/>
</reference>
<reference anchor="RFC4842">
<front>
<title>Synchronous Optical Network/Synchronous Digital Hierarchy (SO
NET/SDH) Circuit Emulation over Packet (CEP)</title>
<author fullname="A. Malis" initials="A." surname="Malis"/>
<author fullname="P. Pate" initials="P." surname="Pate"/>
<author fullname="R. Cohen" initials="R." role="editor" surname="Coh
en"/>
<author fullname="D. Zelig" initials="D." surname="Zelig"/>
<date month="April" year="2007"/>
<abstract>
<t>This document provides encapsulation formats and semantics for
emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH)
circuits and services over MPLS. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4842"/>
<seriesInfo name="DOI" value="10.17487/RFC4842"/>
</reference>
<reference anchor="RFC7212">
<front>
<title>MPLS Generic Associated Channel (G-ACh) Advertisement Protoco
l</title>
<author fullname="D. Frost" initials="D." surname="Frost"/>
<author fullname="S. Bryant" initials="S." surname="Bryant"/>
<author fullname="M. Bocci" initials="M." surname="Bocci"/>
<date month="June" year="2014"/>
<abstract>
<t>The MPLS Generic Associated Channel (G-ACh) provides an auxilia
ry logical data channel associated with a Label Switched Path (LSP), a pseudowir
e, or a section (link) over which a variety of protocols may flow. These protoco
ls are commonly used to provide Operations, Administration, and Maintenance (OAM
) mechanisms associated with the primary data channel. This document specifies s
imple procedures by which an endpoint of an LSP, pseudowire, or section may info
rm the other endpoints of its capabilities and configuration parameters, or othe
r application-specific information. This information may then be used by the rec
eiver to validate or adjust its local configuration, and by the network operator
for diagnostic purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7212"/>
<seriesInfo name="DOI" value="10.17487/RFC7212"/>
</reference>
<reference anchor="RFC4443">
<front>
<title>Internet Control Message Protocol (ICMPv6) for the Internet P
rotocol Version 6 (IPv6) Specification</title>
<author fullname="A. Conta" initials="A." surname="Conta"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="M. Gupta" initials="M." role="editor" surname="Gup
ta"/>
<date month="March" year="2006"/>
<abstract>
<t>This document describes the format of a set of control messages
used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Cont
rol Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="STD" value="89"/>
<seriesInfo name="RFC" value="4443"/>
<seriesInfo name="DOI" value="10.17487/RFC4443"/>
</reference>
<reference anchor="RFC5036">
<front>
<title>LDP Specification</title>
<author fullname="L. Andersson" initials="L." role="editor" surname=
"Andersson"/>
<author fullname="I. Minei" initials="I." role="editor" surname="Min
ei"/>
<author fullname="B. Thomas" initials="B." role="editor" surname="Th
omas"/>
<date month="October" year="2007"/>
<abstract>
<t>The architecture for Multiprotocol Label Switching (MPLS) is de
scribed in RFC 3031. A fundamental concept in MPLS is that two Label Switching R
outers (LSRs) must agree on the meaning of the labels used to forward traffic be
tween and through them. This common understanding is achieved by using a set of
procedures, called a label distribution protocol, by which one LSR informs anoth
er 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5036"/>
<seriesInfo name="DOI" value="10.17487/RFC5036"/>
</reference>
<reference anchor="RFC8077">
<front>
<title>Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)</title>
<author fullname="L. Martini" initials="L." role="editor" surname="M
artini"/>
<author fullname="G. Heron" initials="G." role="editor" surname="Her
on"/>
<date month="February" year="2017"/>
<abstract>
<t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mo
de, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Lay
er 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 Mult
iplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enable
d network. This document specifies a protocol for establishing and maintaining t
he pseudowires, using extensions to the Label Distribution Protocol (LDP). Proce
dures for encapsulating Layer 2 PDUs are specified in other documents.</t>
<t>This document is a rewrite of RFC 4447 for publication as an In
ternet Standard.</t>
</abstract>
</front>
<seriesInfo name="STD" value="84"/>
<seriesInfo name="RFC" value="8077"/>
<seriesInfo name="DOI" value="10.17487/RFC8077"/>
</reference>
<reference anchor="RFC3031">
<front>
<title>Multiprotocol Label Switching Architecture</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="A. Viswanathan" initials="A." surname="Viswanathan
"/>
<author fullname="R. Callon" initials="R." surname="Callon"/>
<date month="January" year="2001"/>
<abstract>
<t>This document specifies the architecture for Multiprotocol Labe
l Switching (MPLS). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3031"/>
<seriesInfo name="DOI" value="10.17487/RFC3031"/>
</reference>
<reference anchor="RFC4875">
<front>
<title>Extensions to Resource Reservation Protocol - Traffic Enginee
ring (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
<author fullname="R. Aggarwal" initials="R." role="editor" surname="
Aggarwal"/>
<author fullname="D. Papadimitriou" initials="D." role="editor" surn
ame="Papadimitriou"/>
<author fullname="S. Yasukawa" initials="S." role="editor" surname="
Yasukawa"/>
<date month="May" year="2007"/>
<abstract>
<t>This document describes extensions to Resource Reservation Prot
ocol - Traffic Engineering (RSVP-TE) for the set up of Traffic Engineered (TE) p
oint-to-multipoint (P2MP) Label Switched Paths (LSPs) in Multi- Protocol Label S
witching (MPLS) and Generalized MPLS (GMPLS) networks. The solution relies on RS
VP-TE without requiring a multicast routing protocol in the Service Provider cor
e. Protocol elements and procedures for this solution are described.</t>
<t>There can be various applications for P2MP TE LSPs such as IP m
ulticast. Specification of how such applications will use a P2MP TE LSP is outsi
de the scope of this document. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4875"/>
<seriesInfo name="DOI" value="10.17487/RFC4875"/>
</reference>
<reference anchor="RFC8754">
<front>
<title>IPv6 Segment Routing Header (SRH)</title>
<author fullname="C. Filsfils" initials="C." role="editor" surname="
Filsfils"/>
<author fullname="D. Dukes" initials="D." role="editor" surname="Duk
es"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="J. Leddy" initials="J." surname="Leddy"/>
<author fullname="S. Matsushima" initials="S." surname="Matsushima"/
>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<date month="March" year="2020"/>
<abstract>
<t>Segment Routing can be applied to the IPv6 data plane using a n
ew type of Routing Extension Header called the Segment Routing Header (SRH). Thi
s document describes the SRH and how it is used by nodes that are Segment Routin
g (SR) capable.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8754"/>
<seriesInfo name="DOI" value="10.17487/RFC8754"/>
</reference>
<reference anchor="RFC3711">
<front>
<title>The Secure Real-time Transport Protocol (SRTP)</title>
<author fullname="M. Baugher" initials="M." surname="Baugher"/>
<author fullname="D. McGrew" initials="D." surname="McGrew"/>
<author fullname="M. Naslund" initials="M." surname="Naslund"/>
<author fullname="E. Carrara" initials="E." surname="Carrara"/>
<author fullname="K. Norrman" initials="K." surname="Norrman"/>
<date month="March" year="2004"/>
<abstract>
<t>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 traffi
c and to the control traffic for RTP, the Real-time Transport Control Protocol (
RTCP). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3711"/>
<seriesInfo name="DOI" value="10.17487/RFC3711"/>
</reference>
<reference anchor="RFC9293">
<front>
<title>Transmission Control Protocol (TCP)</title>
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy
"/>
<date month="August" year="2022"/>
<abstract>
<t>This document specifies the Transmission Control Protocol (TCP)
. TCP is an important transport-layer protocol in the Internet protocol stack, a
nd it has continuously evolved over decades of use and growth of the Internet. O
ver 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 doc
ument 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 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol bits from RFC 793 have also been updated based on RFC 3168.</t>
</abstract>
</front>
<seriesInfo name="STD" value="7"/>
<seriesInfo name="RFC" value="9293"/>
<seriesInfo name="DOI" value="10.17487/RFC9293"/>
</reference>
<reference anchor="RFC3209">
<front>
<title>RSVP-TE: Extensions to RSVP for LSP Tunnels</title>
<author fullname="D. Awduche" initials="D." surname="Awduche"/>
<author fullname="L. Berger" initials="L." surname="Berger"/>
<author fullname="D. Gan" initials="D." surname="Gan"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="V. Srinivasan" initials="V." surname="Srinivasan"/
>
<author fullname="G. Swallow" initials="G." surname="Swallow"/>
<date month="December" year="2001"/>
<abstract>
<t>This document describes the use of RSVP (Resource Reservation P
rotocol), including all the necessary extensions, to establish label-switched pa
ths (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 traff
ic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3209"/>
<seriesInfo name="DOI" value="10.17487/RFC3209"/>
</reference>
<reference anchor="RFC9256">
<front>
<title>Segment Routing Policy Architecture</title>
<author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
<author fullname="K. Talaulikar" initials="K." role="editor" surname
="Talaulikar"/>
<author fullname="D. Voyer" initials="D." surname="Voyer"/>
<author fullname="A. Bogdanov" initials="A." surname="Bogdanov"/>
<author fullname="P. Mattes" initials="P." surname="Mattes"/>
<date month="July" year="2022"/>
<abstract>
<t>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.</t>
<t>This document updates RFC 8402 as it details the concepts of SR
Policy and steering into an SR Policy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9256"/>
<seriesInfo name="DOI" value="10.17487/RFC9256"/>
</reference>
<reference anchor="RFC5086">
<front>
<title>Structure-Aware Time Division Multiplexed (TDM) Circuit Emula
tion Service over Packet Switched Network (CESoPSN)</title>
<author fullname="A. Vainshtein" initials="A." role="editor" surname
="Vainshtein"/>
<author fullname="I. Sasson" initials="I." surname="Sasson"/>
<author fullname="E. Metz" initials="E." surname="Metz"/>
<author fullname="T. Frost" initials="T." surname="Frost"/>
<author fullname="P. Pate" initials="P." surname="Pate"/>
<date month="December" year="2007"/>
<abstract>
<t>This document describes a method for encapsulating structured (
NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switch
ing networks (PSNs). In this regard, it complements similar work for structure-a
gnostic emulation of TDM bit-streams (see RFC 4553). This memo provides informat
ion for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5086"/>
<seriesInfo name="DOI" value="10.17487/RFC5086"/>
</reference>
<reference anchor="RFC8214">
<front>
<title>Virtual Private Wire Service Support in Ethernet VPN</title>
<author fullname="S. Boutros" initials="S." surname="Boutros"/>
<author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
<author fullname="S. Salam" initials="S." surname="Salam"/>
<author fullname="J. Drake" initials="J." surname="Drake"/>
<author fullname="J. Rabadan" initials="J." surname="Rabadan"/>
<date month="August" year="2017"/>
<abstract>
<t>This document describes how Ethernet VPN (EVPN) can be used to
support the Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN accomp
lishes the following for VPWS: provides Single-Active as well as All-Active mult
ihoming with flow-based load-balancing, eliminates the need for Pseudowire (PW)
signaling, and provides fast protection convergence upon node or link failure.</
t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="8214"/> <refcontent>ATIS-0900105.09.2013(S2023)</refcontent>
<seriesInfo name="DOI" value="10.17487/RFC8214"/>
</reference> </reference>
<reference anchor="I-D.draft-schmutzer-bess-bitstream-vpws-signalling"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 553.xml"/>
<title>Ethernet VPN Signalling Extensions for Bit-stream VPWS</title <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
> 906.xml"/>
<author fullname="Steven Gringeri" initials="S." surname="Gringeri"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<organization>Verizon</organization> 448.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="Jeremy Whittaker" initials="J." surname="Whittaker 842.xml"/>
"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<organization>Verizon</organization> 212.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="Christian Schmutzer" initials="C." surname="Schmut 443.xml"/>
zer"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<organization>Cisco Systems, Inc.</organization> 036.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="Bharath Vasudevan" initials="B." surname="Vasudeva 077.xml"/>
n"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<organization>Cisco Systems, Inc.</organization> 031.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="Patrice Brissette" initials="P." surname="Brissett 875.xml"/>
e"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<organization>Cisco Systems, Inc.</organization> 754.xml"/>
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<date day="18" month="October" year="2024"/> 711.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t> This document specifies the mechanisms to allow for dynamic 293.xml"/>
signalling of Virtual Private Wire Services (VPWS) carrying bit- <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
stream signals over Packet Switched Networks (PSN). 209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
256.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
214.xml"/>
</t> <!-- [I-D.schmutzer-bess-bitstream-vpws-signalling]
</abstract> draft-schmutzer-bess-bitstream-vpws-signalling-02
</front> IESG State: I-D Exists as of 03/05/25.
<seriesInfo name="Internet-Draft" value="draft-schmutzer-bess-bitstrea -->
m-vpws-signalling-02"/>
</reference>
<reference anchor="I-D.draft-schmutzer-pals-ple-signaling">
<front>
<title>LDP Extensions to Support Private Line Emulation (PLE)</title
>
<author fullname="Christian Schmutzer" initials="C." surname="Schmut
zer">
<organization>Cisco Systems, Inc.</organization>
</author>
<date day="20" month="October" year="2024"/>
<abstract>
<t> This document defines extension to the Pseudowire Emulation
Edge-to-
Edge (PWE3) control protocol [RFC4447] required for the setup of
Private Line Emulation (PLE) pseudowires in MPLS networks.
</t> <reference anchor="I-D.schmutzer-bess-bitstream-vpws-signalling" target="https:/
</abstract> /datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstream-vpws-signalling-02
</front> ">
<seriesInfo name="Internet-Draft" value="draft-schmutzer-pals-ple-sign <front>
aling-02"/> <title>Ethernet VPN Signalling Extensions for Bit-stream VPWS</title>
</reference> <author initials="S." surname="Gringeri" fullname="Steven Gringeri">
<reference anchor="RFC2914"> <organization>Verizon</organization>
<front> </author>
<title>Congestion Control Principles</title> <author initials="J." surname="Whittaker" fullname="Jeremy Whittaker">
<author fullname="S. Floyd" initials="S." surname="Floyd"/> <organization>Verizon</organization>
<date month="September" year="2000"/> </author>
<abstract> <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" r
<t>The goal of this document is to explain the need for congestion ole="editor">
control in the Internet, and to discuss what constitutes correct congestion con <organization>Cisco Systems, Inc.</organization>
trol. This document specifies an Internet Best Current Practices for the Interne </author>
t Community, and requests discussion and suggestions for improvements.</t> <author initials="B." surname="Vasudevan" fullname="Bharath Vasudevan">
</abstract> <organization>Cisco Systems, Inc.</organization>
</front> </author>
<seriesInfo name="BCP" value="41"/> <author initials="P." surname="Brissette" fullname="Patrice Brissette">
<seriesInfo name="RFC" value="2914"/> <organization>Cisco Systems, Inc.</organization>
<seriesInfo name="DOI" value="10.17487/RFC2914"/> </author>
</reference> <date month="October" day="18" year="2024" />
<reference anchor="RFC2475"> </front>
<front> <seriesInfo name="Internet-Draft" value="draft-schmutzer-bess-bitstream-vpws-
<title>An Architecture for Differentiated Services</title> signalling-02" />
<author fullname="S. Blake" initials="S." surname="Blake"/> </reference>
<author fullname="D. Black" initials="D." surname="Black"/>
<author fullname="M. Carlson" initials="M." surname="Carlson"/> <!-- [I-D.schmutzer-pals-ple-signaling]
<author fullname="E. Davies" initials="E." surname="Davies"/> draft-schmutzer-pals-ple-signaling-02
<author fullname="Z. Wang" initials="Z." surname="Wang"/> IESG State: I-D Exists as of 03/05/25.
<author fullname="W. Weiss" initials="W." surname="Weiss"/> -->
<date month="December" year="1998"/>
<abstract> <reference anchor="I-D.schmutzer-pals-ple-signaling" target="https://datatracker
<t>This document defines an architecture for implementing scalable .ietf.org/doc/html/draft-schmutzer-pals-ple-signaling-02">
service differentiation in the Internet. This memo provides information for the <front>
Internet community.</t> <title>LDP Extensions to Support Private Line Emulation (PLE)</title>
</abstract> <author initials="C." surname="Schmutzer" fullname="Christian Schmutzer" r
</front> ole="editor">
<seriesInfo name="RFC" value="2475"/> <organization>Cisco Systems, Inc.</organization>
<seriesInfo name="DOI" value="10.17487/RFC2475"/> </author>
</reference> <date month="October" day="20" year="2024" />
<reference anchor="RFC3086"> </front>
<front> <seriesInfo name="Internet-Draft" value="draft-schmutzer-pals-ple-signaling-0
<title>Definition of Differentiated Services Per Domain Behaviors an 2" />
d Rules for their Specification</title>
<author fullname="K. Nichols" initials="K." surname="Nichols"/> </reference>
<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
<date month="April" year="2001"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<abstract> 914.xml"/>
<t>This document defines and discusses Per-Domain Behaviors in det <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
ail and lays out the format and required content for contributions to the Diffse 475.xml"/>
rv WG on PDBs and the procedure that will be applied for individual PDB specific <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
ations to advance as WG products. This format is specified to expedite working g 086.xml"/>
roup review of PDB submissions. This memo provides information for the Internet <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
community.</t> 246.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 055.xml"/>
<seriesInfo name="RFC" value="3086"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="DOI" value="10.17487/RFC3086"/> 384.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc
<reference anchor="RFC3246"> e.RFC.4664.xml"/>
<front>
<title>An Expedited Forwarding PHB (Per-Hop Behavior)</title>
<author fullname="B. Davie" initials="B." surname="Davie"/>
<author fullname="A. Charny" initials="A." surname="Charny"/>
<author fullname="J.C.R. Bennet" initials="J.C.R." surname="Bennet"/
>
<author fullname="K. Benson" initials="K." surname="Benson"/>
<author fullname="J.Y. Le Boudec" initials="J.Y." surname="Le Boudec
"/>
<author fullname="W. Courtney" initials="W." surname="Courtney"/>
<author fullname="S. Davari" initials="S." surname="Davari"/>
<author fullname="V. Firoiu" initials="V." surname="Firoiu"/>
<author fullname="D. Stiliadis" initials="D." surname="Stiliadis"/>
<date month="March" year="2002"/>
<abstract>
<t>This document defines a PHB (per-hop behavior) called Expedited
Forwarding (EF). The PHB is a basic building block in the Differentiated Servic
es architecture. EF is intended to provide a building block for low delay, low j
itter and low loss services by ensuring that the EF aggregate is served at a cer
tain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3246"/>
<seriesInfo name="DOI" value="10.17487/RFC3246"/>
</reference>
<reference anchor="RFC9055">
<front>
<title>Deterministic Networking (DetNet) Security Considerations</ti
tle>
<author fullname="E. Grossman" initials="E." role="editor" surname="
Grossman"/>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<author fullname="A. Hacker" initials="A." surname="Hacker"/>
<date month="June" year="2021"/>
<abstract>
<t>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, secu
ring a DetNet requires that in addition to the best practice security measures t
aken for any mission-critical network, additional security measures may be neede
d to secure the intended operation of these novel service properties.</t>
<t>This document addresses DetNet-specific security considerations
from the perspectives of both the DetNet system-level designer and component de
signer. 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 violatio
n detection.</t>
<t>This document also addresses security considerations specific t
o the IP and MPLS data plane technologies, thereby complementing the Security Co
nsiderations sections of those documents.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9055"/>
<seriesInfo name="DOI" value="10.17487/RFC9055"/>
</reference>
<reference anchor="RFC7384">
<front>
<title>Security Requirements of Time Protocols in Packet Switched Ne
tworks</title>
<author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
<date month="October" year="2014"/>
<abstract>
<t>As time and frequency distribution protocols are becoming incre
asingly common and widely deployed, concern about their exposure to various secu
rity threats is increasing. This document defines a set of security requirements
for time protocols, focusing on the Precision Time Protocol (PTP) and the Netwo
rk Time Protocol (NTP). This document also discusses the security impacts of tim
e protocol practices, the performance implications of external security practice
s on time protocols, and the dependencies between other security services and ti
me synchronization.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7384"/>
<seriesInfo name="DOI" value="10.17487/RFC7384"/>
</reference>
</references> </references>
</references> </references>
<section anchor="contributors" numbered="false" toc="include" removeInRFC="f <section anchor="acknowledgements" numbered="false" toc="include">
alse"> <name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Alexander
Vainshtein"/>, <contact fullname="Yaakov Stein"/>, <contact
fullname="Erik van Veelen"/>, <contact fullname="Faisal Dada"/>,
<contact fullname="Giles Heron"/>, <contact fullname="Luca Della
Chiesa"/>, and <contact fullname="Ashwin Gumaste"/> for their early
contributions, review, comments, and suggestions.</t>
<t>Special thank you to:</t>
<ul spacing="normal">
<li><t><contact fullname="Carlos Pignataro"/> and <contact
fullname="Nagendra Kumar Nainar"/> for giving the authors new-to-the-IET
F
guidance on how to get started</t></li>
<li><t><contact fullname="Stewart Bryant"/> for being our
shepherd</t></li>
<li><t><contact fullname="Tal Mizahi"/>, <contact fullname="Joel
Halpern"/>, <contact fullname="Christian Huitema"/>, <contact
fullname="Tony Li"/>, and <contact fullname="Tommy Pauly"/> for their
reviews and suggestions during Last Call</t></li>
<li><t><contact fullname="Andrew Malis"/> and <contact
fullname="Gunter van de Velde"/> for their guidance through the
process</t></li>
</ul>
</section>
<section anchor="contributors" numbered="false" toc="include">
<name>Contributors</name> <name>Contributors</name>
<contact initials="A." surname="Burk" fullname="Andreas Burk"> <contact initials="A." surname="Burk" fullname="Andreas Burk">
<organization>1&amp;1 Versatel</organization> <organization>1&amp;1 Versatel</organization>
<address> <address>
<email>andreas.burk@magenta.de</email> <email>andreas.burk@magenta.de</email>
</address> </address>
</contact> </contact>
<contact initials="F." surname="Dada" fullname="Faisal Dada"> <contact initials="F." surname="Dada" fullname="Faisal Dada">
<organization>AMD</organization> <organization>AMD</organization>
<address> <address>
skipping to change at line 2113 skipping to change at line 1423
<address> <address>
<email>naikumar@cisco.com</email> <email>naikumar@cisco.com</email>
</address> </address>
</contact> </contact>
<contact initials="C." surname="Pignataro" fullname="Carlos Pignataro"> <contact initials="C." surname="Pignataro" fullname="Carlos Pignataro">
<organization>Blue Fern Consulting</organization> <organization>Blue Fern Consulting</organization>
<address> <address>
<email>Carlos@Bluefern.consulting</email> <email>Carlos@Bluefern.consulting</email>
</address> </address>
</contact> </contact>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+19a3cbx7Hgd/6KjnzuXTIBQAAk+NC5zjUFghITkkIISHbO
7iZnCDTICQczuDMDUrDpPfsf9h/uL9l69WMeIClLsp2NmROZnOnprq6urndX
N5vNjUkyDePrl2qZz5oHGxvZ8moeZlmYxOPVQr9Up4PxycZGHuYR/DFMw7sg
1+osjLUazJdRkENDldzpVA2Dya3O1eg+zCc3eqoudH6fpLfZRnB1leo7+Phs
sDFNJnEwh56maTDLm6GGQRdBlDUXkW52ehsT6P06SVcvVZZPN8JF+lLl6TLL
u+32YbsL0OVBPP17ECUx9LHS2cYifKn+e55MGipL0jzVswx+W835l0kyn+s4
z/7nxkawzG+S9OWGUk34v1JhnL1Uo5Z6ncLkdRrSQwZtlOs7HRffJClg6D38
9X0S04OvMhhM5y+lu68mYb5yfyRT7f2xjPPUvVzcEPD8l54HYYSTxSFb1zLk
N3c8UgsmUIT4Ty317U2Y58GtTj2Q/6RTPV+VXn1hmP9BY7buzZjrgb5oqTO9
mgdx7IF8EU6SKAgLbwjiY73MM6AgNdaRvqW+PjfoFy0Z9Zucx2hNdRHkfkuN
JjfzZf59Ac/9mzTM8jCIS28J8H6YTRI1WsFizoH4TuNJi16mCW4dPQ3zJP0C
k5lkDMo3Exy/in2Yyqs0uY/L0/CeCvg6DlQ/SRdJStv6S8B6hWMCpDAUQQrc
Bz4Kr5Z5ZXMeAdzL9NYD+yiepjrI3GOCu/PvHaTyDDhH9AVADnjQ1hUM+s08
uAZ+ElTI5aSljoNp4MF6EoRZELmnBOrR+fEXgHBGQ7WmMNQ3wXxapYDXQMzz
IIr0dQDsxQPytU6DaFp5+bORw3XGI3sEUQB80FJ3sNfea9ilPv0O0vC2/IYR
HM7vsMfVFwAWuNttCwa9ozG/CcxQVbDPgBp0FAH2bkKd+VRxtpwE1XePco/P
O4loioNPbtYxC2DVF0EYBz7Tu0CiB3mt/rycB6n//mcEPA7CWxz+ES43DK/j
IA/SxOd0QRolWekVgf0qWmp1otMYaDzOllEOovdLcLwFD/3NNf4tcNu3DN43
CMsMQIHXFpSNjTCeJekc9t6dRtZ4edLf7Rzum193Djrya++w23ZPe/jruEMv
lRK9Df5WTXUSgiIGhAeCT1il04oEL0Ecfk+7HRS/i/7peMS9BOk1YuQmzxfZ
y+3t+/v7VhgDYrIWfLONahYoAVpn23mnA1+c9JvD02a3AMKpmQ3oi2M9uYmT
KLlelaFSw5tVFk6Ac57GuU5nwURn0KarNqXPrU+CW19lIGh0K4izkEAnfTJI
p9k2z0f+s9veBY1zjzqZgmB5qeRPhqL3U2bWrJlbs2cm1vuZJrYPxEJr5Cbm
LVkvmHc+19zgYW/7CPTvKergqmNnun103vlZZwuTgv8UV7PjVnPvM854z8xy
7+eZYa/Thbn0ilPruakNP+fchnZyw59pdjs7jy3c/nMm93//9/95xvSQyeyb
6e1/udllCf4/1JPObmev19nd77a7xd3Y7eBf8Oh166BbJM1BPG3mSRN2FCgj
aZKqBQCPc45hfRZBChIPppOhyqqSq3/oCYqOTEETkJHwJibggwgN4xiBytVV
mDdTtOin4XWYA0YWQX7DPUCbGLuApk+jw++eDDeUCcsYkEzr8S7GfzdPx++2
1HqJki9BquTbqZ5sj5uXg36TUFBkwt1mpwtPjsano2b7sN3utHut9mEL6GKn
gKvRKp7cpEmcLDP1dpHTaotHQm2O3l4Mxluw5ObJINLEpMbhHGQvTd90IHN8
EgUI0UfTA3zL/8hU2sivdjKggp0i0e8QUWxsxCWNYOeQBT7+2uu13a9GOTg4
PNiTXw+7va55utumX08Hg8FBu9sq4g6fqpEASeQzyG9gfXX+NCHAp7VYsHNu
hVprQgP+sk2jb3dA3na3i/ug22z3aBvst4sb3SxaDLoYEzYxKIQTwFSZt/KG
qkHXToN0crOCtT9+84zt/aXoGeZSpOf9ZrsjszwssTPLmszMEqHjPAVSArMs
VzGj4pecz2Fx1dpN0pNw5xaJagwTIGM/iVQyU/9AhTGlnXYP/8Cv92F+E8Z2
yWRqmbq/CSc3KgAGfhVkGjhbTMjotncP1C3wr+3MLe8vyaiKO7YNiNgRRPS+
KCJ+1fQOk6+iRXkSbveL4qbT290lIvmV0MjuY8jYPyjuGNBX0mACsKDLcZIh
Qp6x1kr/1zJckDSbLeOJzOIqSiaApl+QURyU9sdeiRB6nZ9ECY/yRbX5dnzx
y1J/SbkD9aVjdLvShJ3qkRVVDxVkC1DEMpB1oJ5RkMXQ/S+qmJWsyMNm+8BM
rVs3tcnj9OzoNouCO1h9JNlfdILd4gQP/LVrFVdPgl9THQUrdRekIY9u6DAC
DMACBotFBIBdRVrliaxlkxkWqO43yTQDEyQFROh4siqTwS9KxzjhIjZAPesa
bPTK2ICPQwwhwoM5mCZpkicT2Mg5g4QPZmHEKtts3Xx/0en2Wms27mW3VzI0
0JZQY8t6xBEKxkUfoAEAXusYSH6i+mmItB88OS+YySRJp9KyDLTgsInewVb8
j6leJHkLB8iyJG4BwW1nME5zch1uh9Nke5pMshb88Z+nx193O53OPtgSO3uj
wdFl/82/H7/tvzsfXIy/fn3ZhHkVGfRhs9Mm5ny5e1hUTauTNXO8xE2cki0F
pDwevb7ccojwX/5KkQAzrSChg0g4Pbo4ag6RjotKOjxWL46yLLyOYRMzRQIf
GBqKv1jOr8Akf6Gy5VUz1dfA+tJnaCAYc19LsUEckP0U0LCEzm2zxZoxD1h5
0Ppwk8+jr8qPmx0zudHl3V5zEE9r5oev0PmwSGCnqFf6JrgLk59hUpm+xl+a
abJEl3j5b5lSlgLgWqBrXhnoNkiz2ECjudlsqgCMcJQ+8Of4JgTtKZksSdjo
DwuQuRkpEoY/h1GYr1A+3YVpvkSviOQ93AP9qkyndyHaZZvvh9+OtsiHgjGD
ABhbsIqSAHq70qsEJPkY2d9xeMfM8Bxd+4tIf0BpuDk+Pt9SONkgYocLrM1d
OIV+F5leThMay6k0qO9gQgN8D4Dwd/Ia1F7kn5SFIQpCZrIwrIa8ORxdbLUE
G/NwOo00/PEV0myaTJcT1jQAjPMkx8kiBy6hCmCbpOEVQBiIvFITDIFN1+WF
bA7PBlvE5QHAYJHRc5h7nOSgoUerj8BP5qP5vSyLGfZbRNWIl8WsyqM5KYIN
mDysO0wRiDhIpw0V5oJi5mBGKJuJT1EF++GH/8RIS6+38+OPLUGRtlPOlp6g
J+dZA4wTDfBNgjRd4cwsczgO8gClFPLK4fG7bAunOdWzMC6MdNje+/FH2Ezm
793dA/gbRkU0atCdrm8aamFcmqCAwMTr6IPmSSx4Sgs9xeFJAgeknwFygQyW
qThVFqnOJb1nRrtjyPSZqsH0GtA8hKW9T5bRFIhdUSgMv2FSutOAmbdAC/pD
gOgkXW8JFtoElB0EBJbBOpWMpxHA6i+zPJnbIfowxFTzZkOIEYpYa/ZJ+R4+
29UPP7C2gghbaA5cA3z5vdZkK8xpHwH/oL5onnMNUgaIaDiwY7FTSWM2DiIo
mE5TDXwJddgknsBIAM4VduJPgUwVp+r4mEdwYYHFNkVCCLVzqlmG0jBsA2Ez
jIwJIiRSQjSeaxjIfXuSpMu52jwfnMBmATMhnBm6gxU4AgqBdnYV7HIFapQn
aQA4PoINZbYFbbvR0QXYkB9yHWcF3MGCEcFMNCIna6m3jF+0WXLo0Nuekb7T
kQLOkNyz8yrwnMm2x6JTXhhWZtfHXwPifUG8MpRY/NTifK7BxIjDbO520dUK
SGLc6dBWPYqypMEK2zaYyriu29M0Wai5YTzoPQd4J2mSZU2BOYMFQ6gZIker
awFFCOc+K7Mbi6nYsmQHb0sRGwmRs97qFdj2YCKx8Y6WQj9MJ8BX1mTcwTYZ
btXwjYPdLmwDZj5TXYAIwSg8CInJEWuADkDxgu5hYN5DGgMNouj6u27I0g5U
A1hvaArEg0wBOzcceky5PUG6ArY83kLcIuLN2z7smgCgTuFtH9jxKAhp/EDo
9j5YNTBtEEQQikXmP/AW2oDKBzIfpRIzPGNpLdE5EOtA1sEtdqGZ8GRgt4A7
7t1MNWDWkAUgmYSQUTZrcTk81itJA10kQ09w5AVhOktwf6BmEU9wGTLg2fMw
CgjvI0MxzaPrOEFz+WlRWSCJ0dE4qSUKFlvkXilqOyjFSBXCXePYUAzMCsDM
oFPYfEOAM0wsARyLC+qNc0EN0QUVOt/15rjTUAP4/3iHEDnY2cIJEnOgAZyG
gzJCxP0sBStxjjt+Gs5gbyHCchPTCxFXKEwCx/gbRZ7g73IQCWi0/fjjNgqH
/fY+bAqE5O34QvGTQ3ySq+vwGpCRIxvV04xxZPUP0sWArFB2ZjUqn3gg74sS
nMQmaXOso7gNjAIOg3kiS79FvCAKwWwxMhig+52EeADATGJxaqcF/6MZ4G+7
LdLiCobXRZJb/U0TPwHqBDXmxfm70fhFg/+rLt7S75eDv7w7vRwc4++jN0dn
Z/YX02L05u27s2P3m/uy//YcLKdj/hieqtKj86O/wn8Q1Bdvh+PTtxdHZy+q
O4Fwm1gOi3oHY7mwe171h6qzKzgBIw4Xjf846OzvMqOLeTBSLflPWIAVEroO
UmIsUQTcfIFEC9IWhshukvtYIS9oIRrHoA6EEjjGni41ER9olefJVEfQpNBm
Y+P36qj/BkxcMAGTSUjkYcTSGx0gF+V9t9/tADPG5qcjbA77fA7a59T4KkZE
Z/y+eQYtSJOGP/ARfbHMYc/Ncdex0U0vXl3WvVKvmIFfgnjSKTQ8HzV5XMs2
QFtm6cJDvDod4+tXyzDCZHAyZK9Tmo4470ZL4BYoTOsirzSzPgHTN5HlV7CT
LqEHfDPAFwXVjp4O8fGjos2XZPjJ6LLPY3DOKAGWLC/7WlpiDJRaHg9eQ8Nj
nMSU98Lv1QCnOMDAOUwL5g8sDp6eDLBLUKPuMdhJrzHrMWX8QIPT/jkCam37
vqh656ASogZl1XmrnjM+KIqK3wH7zmEhkL8NIug2JT2dmCH9mcToDR3E17Dk
oIDgp5RdYAa9MC6uvsmzIqVqTb6DidtSP9+emE6+Ff3uRGIC8PbsGOd1FlwB
sR6jDU8ohd5KM+q1d8AAachfB+39fZrfGfZ9luBcTgKgK3z0lp9lmXo7UyeY
kEBPz72nRIIz+2rkvbKb4Gx4So/v1TC5B2o4RWMVHo8cwNakG4KoRxIf4NB1
yjG+HJ5Z6nez8ztC1AgJtXc6NL8Lgg14qdF0EwbugqC4oCi8NTqhU5B2GRlp
jmlD67fH726huUlBsCafusWXIILcO+dWE32cWhQ+d01sH8P+yM9o6dNpDtiu
V6SaYINjZFBPSm5q+R5b8tY7Jlf2e+PKxtdIzkUjEJ+e8eM6BwC9JjRKp5WV
Hp5dlt5e4pf45vzIn9c5WGlg6BzleTC5QbFBTY5rmhwbzRBbjC5c92UvAL4f
Dwl4464mJcsQCL7/Fl87d0xpcVFs2waPSvjyh10alzxW0IR+gcd/IVz9BVRj
1MgQT0xe8OryGLfEpZ4ngOVjEEuT3JMf2GD0ftgcD6hRlixTIEr4Bb4Pinsa
SGgGNqLlN47ydw/2GbrLcR/BuwTkGGZXYgmWz14SAi91EJGn39Hnug/AvIQP
6qxPeglaK73+NPXX13WxWyQTJjkRCYjREcmDEaj4qQbJVhEMI9o3vr1T2TTY
6pQ6Z88kMCr4F0xwK/cx0YZhoN3zmPWEjS69vi7Zy1np6PJNTaOCsgHruCtt
aXlgSqhRPmOV9jsd+fBur2YUwvHpEN4hH1tEQWwEL6YZ8ZcsokvZU2ukNJuU
zceStaAVUyMBLSfT1pHlYfeQVxwoAj9ZSzPYhASs9ErBZfg9jIl5Gu70jlSv
d3FwF4BlhmE7Sx3oZIR3j3oiS5v+fd/7QPQefDz2Hlt7mXV3dE+x/L4vyW+1
CcJ9C622JfqUQH822jIZHeXQPzwMcs8Lq8mGUWzDkMMrIU7O7mP2U4j9kuIO
yTBDUHQiGMnrpvxVqim5EDdwYQyyU74qa9QZzzO1T+f4lB1m0DH6RKJoia77
3Jix0Pbv1ErsOGwTRyh3rH1e7q5gBhvNd7fVQZXMrlDLeRqIISDTRP4O9khz
weIdFqDBUfgUiHRJxjrnKUz0ggzYYI1iQHwKNIctuzLrgOq2ukWwNjb+F/xI
SMX9PPwHOvIX3YU6674fXhgnomo2//hQbVx+4L1a0xj6R+mZL9GYgT7XNL7z
/i0/LDT+Q9P8/KHY2HtR+ABHHA4wG/bh68IPv+hWwMGO/rB+BHq94Td4UBdm
srUYsK/lo40HMFo66oH+elAjeIsa9kMLf5Ah0C/yEF9Lwz4A++BG/ht2PXx8
ZHr9Nzey3+A582TcILQ2MIDdrfv5myIgTVscziVWVqEsQ+zariFTjo8AsTsq
/SQyDawaWGnoXhW7n4ihWfMjr3if/fBSfWVZDMdBv36BnKHEuV78uLGBj/X8
KiVPF7l9QYDMQQclhNyhLgB72rr4FIjRqLrn0Y3TK+x5653EPsnrDkxuFoEO
CmwkB0m5vGZGRwC40Bp0xg7JAHnYRAMjcn5qmJAXHFAbG2AdqQxMcrso+Woh
80AbxzIqihuBvhBn4ZUkbUjiOekExjjKTNJdzByQ4LZQkEcP3/YHLTXgeIS4
1cifwpGEdWa42gQzfatRaIudkXnEU0aw0J6iiAko0MYbT27uJqkqjou31NEM
Rb7MlfxEtG1hrteYy+CGMP49CT2Q3GdfX5hJKGeq7sIAWL/jl+gJ9p2clMtk
urAeT9wPEqcj95fpLaD4g13gaTIHxYTcV15YKUfvuEi7iDFufODl/LGyOKTg
n15EyYrTrSY6BjMvWUOeu0CeRiThATQUu6n2c5mwP3zEzjT6GN22f6dZr5dg
Sv2p5tkjPKDy8/oTv69yIPy+lrcqVfOcJFzp8R2wfVDomiWhhXKLn1c63FCe
zDU/LFTW/fgN3UxEPPlzGXoPiHTt826xIcsoB4nt/49PQOI1dJBUUPUUTqxs
Kgs8X2g9tTBuOUtE8DfVr3yk1DF37r46Kr5fR0kPxa9qgWlaUVzQegbrvir0
/4xGfygpS2t6On1uX072uZ1rhN+l4S/m4MXIMAz2DaMkRCU+Il9gkk1AZQ/A
wM8A6xgzAhJEDnHMf3SJVWD/bLYEVKUD+AyPeSpBNE/CG8nNDQYej+YAL/bJ
DNgGi0IAhJujOQL2y8okrIQ+O4ThWX8vAIBSiEMU8J4mTGJY+p5oG8HmD474
tBT93lebbmanW4oCLVeYBoHMEtC5Yg4OPaVGKCJ+0PqCWSwzI3XQTs9ykJJ4
uhmDnvgQrfkbMvRbLL3rzTPskMwYgyXObVqH0D/Z1Ar+u2air2UBi5OrmUmX
Z9KxkVDCubFQqfsJZ6L3pcvaJcAlRpUFI4ITDCyT5PRiRg11xSkcKIjw/xGo
S9MVaDJ3WNJA3esoaiICr6IwQ5efmGiSjjC5CfUdpXPQeCV52RBoYLGCKEuY
XlKh1mx9wmpDWT8BzP/bG8xw5RXFdIqU5DwHU8J4scSkn+A24NDLurAKRcyz
ukSXcqaQTXshbJYyrRHVkoJc/QiTBG4w4VqUkIQIDuaLOiLPAu1h0vVQma1P
7d0cjofV/CWTS4vhA07eKeRD18wA264BhwKdA2NJjEwW3g9fGeuiaRJpfpS0
rEJCjJe+hqC4lC2kMtMZ0XEAmiNsuRQLYhDpeZHnhg09j4/PG+vjz6yNNiRY
bB0tuJzGuTn13zRKuPONA472+k92ESzfvdQi54pJw0Wt0biOaSNeey+Mto/J
JrGfoEVZRxaiev8Eg1N0m2xsvKMTGcRlsmw5X3Deyo2kUvQHzatkCTMQBRvT
1soGBYb6DWBm1Zxp0eD8IgMZ+lmgPbE2yc0xqrPjoP6URYdnrpRqBqJo5ABd
Z5yWIbxfoBG3VSVXa2Oj8oh1YAQepU+Q6cxgtXbJ1yN4t+wAolDijUcghs+R
6ZMVjmhyd/ZgJy6Qi0mEJs9F0rbIwDEOgs3hm79ucZcNsBRSLZsdnWHSdl2Y
Cb7tjzC79C16iIkzlLI3PPCMr4DNTdrrVyhlZN0NRrwpSAIYHqwgPiTZKGU2
Z3ZmshDX512GYExRGVlRoJdO10APkWaLEBs4+zD3XMxI1mthJnCugsktu8At
BimVULnUpM3h+fEWHweJxT26tk8GlNZlmSfNWF8nuZwi2dQfyL/Yabfbr4Cu
mt9tEa0VRKQlXCMjKeEtqlIu619EQNdms1wFWXGriAPYgGi3pJfbhN0Ad2aC
FDGO25qPnVd3s7/dxBv8FU/paDRofkd8CoOZTFAwL/fO3yqZ2Sh7zAN9MoHZ
2+N/B6+2O+1XCgu2iDYC5rkwosLOJ1UJeRI5SIxJLW4LcmKIl9m3vVEVKC8T
qiQlXwm55TGjx5+MxUiNSjbDSLqjZAyemhNhoD5lGSkWnMpa4auAHIq2gtqD
2QYppcAU/fOpLvqFqJ+zJjKlKy07q1HsvICr86O/Ym4iWf0owHMvfBIQUw0W
oBIsUsqoRbdFDqYCqpLi6PDzo5BiPbSAJo9r6SjjNb24JAR0e/LXRpFOMiYU
07SGTnYPix3Utem096vEVDhMGqi93Vfbe3uWoIptbXLW/i6N1mkfAF3JUChm
LUtCLiQsNpxZqZOvJ08yIYzfi1V5w8keWSf8qKD+wzePbwNUB1jbrSff2tX4
VFouwiN0PAcaMowJNLZgfoVHDHz8GwlKYata/oXse/w4esSHqTYkiYI7RuA2
He20uq3DCmls4SekTSJsFNopfNFp133i59XiHtFpRAlkbEYhJGF8F0QhTNVM
U07t0jT5Eyn8YdLNrQTM1PZguwTGbqvTqYcdbEqd5n7yjto8O9li+Ei9QOvE
drbnNE6/J+YvX5ATwdJcJDnVQqhHDEhOlLuon6ARSMYCG2dWoS2CRvPG3lMN
onvCRT/YwR7z2QT4DGgz94ElZT7k7mZBSvVX1smSkJDHZMSmOnkRYCGmS9pP
0JK92sRDcSfTiuJmeKVnCR0viqdWLjttUSi9P3iUPyNh0zY2G4ca1+2dIq3s
lda2xUx412z7huoVOADw7UcY8u6atnW896DLOZszb4Q6Fr2z81Es2hNNU85b
MPnuCnW27EkWftj5dXLwRF1jNCCYYCjDUMXjbLIOtpQS7H1GiIzhqs4f4kjl
oIvcrVvPVJgEYjxr0Mxu9X35s+r6FT9LNbGfAjvlL2t4zyeIsmfQ9E8RayjR
yDKN5Pzis8QbHgiOwu/lRNZT0m4SLS1rsONAh+ktbrxHpOHnEIaPLn4ZGsD9
PLlDo7L4ee+fUJgS5DtrAPlYYXrQ+YWE6b+WLCUj6fNIUo89ekQqKCns07JI
rSWXK3Gye/nWRUpb811lh8kCeN9n3ME+c7OdHZNLVO4MJXu3XeB9u4/K87WN
ayV1p6oxPy2p8TeJB3V7e6+2u7198xoZ+XQ5YSmIohyJgY+wBbdA+Ukyl1OG
BWfPWmH5aSLSrQMtJMfSSwIPUAC477XWqN+I3LOSyJN+yOUS6eCuwAhNf2uY
L1L+VHMd/+pHa+TuAnZmE798fMha2fscfm86+CiObz5aswdMrMtQDH5LHntH
MrDGZn0rvVaNfOj1RNa5SgEFwcjO5mS+0HEW2LPya6VWzQSAFZN+nz+pFODR
w0eF+WUFmFDOnKO8SZzrnaA2rApQAtyc9pnHDY3nHAOpnHHZ6x5sY90sikFy
2CZB3TXCz/wePbYA28/jCsZbfH7kog3Gl9hS3ykuPoHd7O3BwDnGg1GQVKYl
simg83DI7gBQTeHc737fbe/uHxa6gi0NGMCqlvQZB3I9IBEmoNElTeA7nGpn
j5ZxVgS/2m6n21JVpHvQGbc/85WKPoEIWy20an9ot3l1MG6hYWlB3l6hHoj5
5OITu1rVSVun79BWIzqaf4pLZz1T/4za72fwv6wzHD5aZ/z9OgKzzOvn1SuZ
Le2sczD9plf+y+iVFXlmRBh06URbiXB216kD6wXr7jpl4BnKpe1ijUaAafKk
iNRqtubjNdoA4Tiu12B212kDVo16fMiDdSrwINbp9UoN8DhUWIhRbkJbaGRi
svvVLjhqJN4h0kuNe6h4ahG27PB0C88cm3P2fqy2pcb3CSVl8mYTbZq5m16o
LIJ/4Y9ZkGG6563e2Di2z+k7E09HpgYcDemVNirljS61o0k1QWmDRFsIcr7h
PCgvKp4tF3Q0COHEc5gcpbGiwQYROUcVxjG7AnanhZNhk5GNJw7Y39nptmOL
BeaZ5ZqTbLfXNBF3WcpKlKgqgTkeBvMMcxH4PV+s3YTXqN3VwN2g6WGkn2fM
Z84p7ac0D6NcTSS1BxMCXH2Bkc0IcM++fEoAjuKVWfCox2TTuEoHfMzq0dZc
IeFTA6WPRkAddmriys/SNBp0wJhqN7w9AViPCxnmojbVqtY0z3UKtc2Qx4yF
4B4DvJq1GQcyHVj+paOvNYn4pWT1DXfYvyb4WmOs73GcyFiqhmpmUqjFZbuY
ygTP77Zj5JMQF3dKpOi6RU2YdXbCsKJZB2CQmPNixVI/bq+Vqgd98f2G+wJv
UaFcMEr2sLeeYFM5sf9Ejk4BaD5vJmVnMmMznfSbHUmBIDtBEjV0tra6kZ/q
80gCThFhz8nC+QWSboCvYfEV5adViIRzXJotVUlveYQOfgU5LpTI8Pqk31Bd
+ncX/qVhD+AXjEDJrTYYfxK8Z/QBh9nhl5YyjXrCze3fwbxDiohRQwqdP2kZ
1jPpEjq/cHTfckMvWcdszYDKYXFWM4jkzxLq92mNauIwuOuMPjFArMlX+Txz
bNwyHbM91J932q19z5ArVZJQmxdvRyVr7ue21Wom9POYay1H+5aMi/r0kj/0
bBlkoAe0i0wFIeq9Ii4rFlbRUyBeOIaWk7HXIiNJvflhPRB/tVp4H6Hp7lGT
8El7sBCsr+4Fw0j2cIN7mKtnCLxpV9Kc/cocxK6JYePmOZ3R32Fmg9kwgfky
y7kkE9WYkDNufr5Xbo7LixqwOR4DPU+X7M6uMowrerFcgJa+1uX6aTFzgvmj
s55+VYzw8Qgw88TPlvW0hh1+Iffb5+Cy7Firwt0Z3PzGaf+Fk5cq5GaySHe6
hgnusrrZ6R4UueheQfdy7e37YaFBoZsG2Cuw/kQElqXS11hdxHhSmCisTkyb
9AsEJus3JGZjPeYSr48dHnYwcLjOW/glwnD/8btmU228OT0+HlwoLiI4fkl1
R2EZTkbN3QbHxS5H5GUETojpOgM+B2YCyKmAQW9MUGOgNmkYP0C9JWVRZ2EK
26Wn6IYY3IZkaRgeDCvVbP7x2SHCXygY+JMDQJ9dxH0mscN0sreO+n4TPL8J
nn+yiEx9eIOYbLeeHdZHcdbnFZGw29slrwKy0kc4aY/bscVl3EuGr/aQX1oP
hu8fK/HQnd0NZo5GTu4XxCQPIR6kojvI2h0/Q3bOpgdvbTKLVEVh7w47qQTI
WLvzh49l2VDHa0XlM/JkpIM1YbWfKGtFgNeG234TZz+rOPvNivpNmP1TCTOR
S2tC9c9KFSCetjaVdU20Xz6qlYcYCsLqTi4AhH99+bAPjvJUmPXwqcDpI84s
s23xGRWzsvmtWKgkuVcdoOhoOcfc3mZnVyRqFDW/12mS4W3NWFlCClIBXyTG
RpWi6AoPzPWjCsQcXQtqyilCu2S6vKUG5mYAaW1X2gK1eXKk3lKB/xJwneY+
7vtbPKaMo2AceH3dp+IP96G+ooYdfravDui/MOVO7+kSNvizc9DdVa74kF9+
x6/DY35Uq6VqHlNdnc6DUjRT9aCOANnt7OPKSq0D42P62EhVtzrox1W3Suo+
+Lgu7tUOfEA0ZKngI7v46tOhUGr307tQVTL4OMJwRZL8TWPKJA0KG46Kn5vK
SD9JnyF28BMSJBpUcB2Zy9Hp6DnO5zpO4VQ0zM4lToC11p95pOgeuIypvMSs
DXu+Wkmeq4nm5I+xGqk+WwSurpygNzGctPH/Z14A4NedtIEz+4iUjc6eO1ng
3V7yWBoFzWhQqBN5RtXhaQ1ZC5eL4/hOAS7Z5FLCbWU/hBdkBnblCvvV7aLC
zlGKiqfiD9ZIpAuCsBjdsZ4vPxS28//Y8Hb1Jtbt38Za1FvlXf/HQkcbT7EC
er+tZEAulp19FNwIOuDCFJ7+FvXlAtzP6Izhhl4YgALUWNtLiniXoH5Gz00f
TEVXb4xY0yl1VkCvrUBewRSCye+eidlnwuj4JxKQX1y1hjiReYLWVyEYr/K7
WcjyPYUmUS2c450lVFvI8NHc3ZTBBaaI0nFXhubeP7MvacSai7MQIk7qESaY
J1gVPgu/11wC2vEPOZdkRx9+q8zdOwqLumgOZy7wuqrz8Tv/pjp4GKZcMi8r
1T2FuQ6/NWwt4NstLFCmJDjWTKIZRHTNhb1cErsuTcomvFQu3XHacc94t7zC
TyJZpOapKcUU4EVWeM76SoMRRVOrubJDbZ5hNWy/RhvXbsJbSfx7R+jOsFId
+s3R5VahLj7d0od2Dl1toOVqA+gTrwypjmHuSpBy9F3ioTjOpVokWKgPy4pJ
RfneHjE6wTUVxq/FNb2xCUECcOjuA9gcnR5XC6T9zk2hcMfZ46tkYvruVkC3
UHuySAA590q5q6uWeoWhqgKUAJHnFZgtQWhTcX+579DIgirAVOyfyx4mc0wa
wD1EvW32m/jfLe62toPT5nFrCiuVN0Odz5oZlke+btItrll60zQ9wlxgDKEp
RLJkQVzoe56FvYcWNuF9omJ4XiyFbK+CVW9azF9aZ1yK0vu7damnZbOuWEaJ
yNzexkg1hKd8l1+xCi6yE0Ix4gFHYVQIj/BBsJ0V6vEHIruLOg7MX87/BLw4
wljkSkRLaXInrngccIe82WLQvf5INcCLk4UPlGobIwq9MVpoq4/p+YfcdAy0
HNkP8C4K0eMiTJl210ZKa5NQYupgomME8DR+ddSxvTv/gdcrFhqC9okUcFjo
tEh71vNEpECbdsW52xO+UxAzud0+tMnjkuROl4iiKybTJB5mUXANShz+A/MZ
n703mRRlSrFLx9XzMKFmbsokCPh1K02TLffFp1p5JSLgWbCgHgZA+QIJ4R34
51gl3jcSmqm/EXPdvZEEdnIqWB0aWHoe8kXppQ2Oi/lrXwhaiVQzeb6w11DT
BnA3UZgTmd7NfIVbPF947EAuLYauWsff4fWE/At3eTH4btzsIzKpXJv/6nIw
PDsCLZ/fPsUzMobYDYtf2FpwgGLuu/sof8UL67gaJq4zXRmJ9OBxIfRaUrlS
YTQGYoTRbDu7Qa1cQmShuBvSgvG1eeS0wQqO5iY7Cd8UjKbTliJReGH4CjIu
4UlMZ7yg7FIf8ZWmXBnYg6wB35O8K0zrpdgTo3ZHRiEg33BqGtVuh85/UNCg
C3ShTmfA53hGYP7qWa5+97Vqb3GLnRbppyN01SITxVvchgGyQExeG6YJ8Gzr
VB3xhUlHsi+cy4pQ0MdQVFttYlX6WGMZ1gIzRFcm3X6sp1vep6QqJuQ8NHyP
hioATD00vK+ofbpc5Aap/tUjJPjDbIIl8pl/E5/G6e7idH+EX3r4C906wgsh
3wuDd4w8jL0u4Lu9FnxO6Gddx43rPt18twAG0CT1fMt0RCqvAAvSns37QJ2c
4nHjPF3x6lMKL90MGJpLNGFVPo4kcL09CAwAdLL2669JqqhNxwC2FJCCoRW6
Okv2EV2LyJxQujBuVSpqV5ZimaUmcz0Bp+zNJf9RvEC8vLRHeD1+VIMImMAP
ZlHMXTA4d+aj3lU09jIauUmpsCBffeWbjezRgb8FeNrlwm05AgfvzBEqCuxs
7pIfJ+O7eak9F5NBbX0WfsB4DlovrsB04aYmljLeS+5hLjdn44GpxF51UB5c
1Lay8cyzEAVR5E0FbvbQFO/2uV6GU/KQuDttdw5MKqzvqvjhh8m981G0a2zX
Ts2zbs2zHfi6A2921K7qgYKNzulD9RHPwDz+xP9tPLQV/e/h7OHyAeyXh5PL
12h7nw0uPLsd+Z0Ev+RgvLXTPwMM1nyf3Pu2u7+sxuNJCVXtFofFnfYSh1d0
YURqVcE2eTxd3fZcgniOCEAPWH+76uZR/82W05SHhhH5BXFpf/qakkBRUkrb
8HNFBwkl5VlJGYXQ8nsSZgXgyvacDSbJbmbaFNHMl1oTy88M/y32loo/wusW
LOfk/iXqaGcbG3+E9c3tSbdBFVq+ol1KOlgWz1o+7SYOpEokElC2zq/M+JrC
XhJtCkbjXHUSqF6Vz3Iclb+kdALQHcP4H+jMxpG8b+SKGBqJwtjBNatw7PYk
lfRSleZbBKZmoZj76g/AXEPcA5mhBqpOYF3GaL6zWwbv6EnFlMdyvsTcGajQ
3c3rJ8YzRmFywhMpqmgIaRLpIPVOIg5UIqdrC4BYZ3NlJDw+Jp0wCkbvEQes
TNocxZSudRSv1WxJt0UD1cgd8qyTlGgbo4UGLFxAyVIFZCcewKLRsbUC/KU0
9if1iSRt71dD3xxq/IYyYYeSUkRYoNGBreHop5QdBFsjkOsa1u0w34jyMBBE
98EqKwPNFytZG2QB5hDpLNOpO+XlfHiAVxuTmQcRiiw0hCQ+wPYVrWSD6mXj
abFrCjhjrXciZ2rOMyUxaxBJxdJlqUt8W1CvshI757l5t/4Zh5G9RmP4rfmI
dBMThoA546UIzFlylxxMmQ7mVI46dcTsrtgIC4vgLtlbRnoN9+u5q/VIgXBq
B50omfBF5cbC4IIuntPUxFWoighpD847zpy0rItwt6jQEFK86zZgPe70yl28
YO9MblV6qvPNCfwUxDEop2AVg84c3bM53a0CC3trbOm8pruatGEdndbe8y+8
ZmPZXCNFkRjjopYLt6gYDG2kVDf1BzyRiddeJeltqdQ9xZUIrNw74Y8OP5x/
nizkdgMa0t7p4A5CulsPBFdWR84aLMLMddxy9ewmXtW9BapbhtuCN1ij/kbZ
Tbxudqvhr4TnA2w85/bSTbzoFLrQ+aTVsHncRd8c4o/u6KvTPL2xyQT2tcg0
X/x/pEa+/7r7MHz4DtTFPt6J9HAuYbmxqlcjLz6/GvlYSGls771Z//O5Yai5
q5ZIeEQk7F3p+5lhcNcN5jYW5hgdatK/V+9fqvdggQJYRiLc8Z/1cr5LsmT4
Ug15y5mPjIhD99pn0A2+e2n0b8sHzEjfFTSi0hD13Re67vdfKuQdinwqpleg
1c+l15y/VOeUuGb6Pn8M4o/oeDh+aSOq6JLA/o9wY3EpMSv0I/SH5H4Og71o
ZrqKg3k44S/WyNY9J1k7UlRBgwbv3f+UuJsKWUulpFsHCHt0RZ5RyAI7cd+T
G1UCka5+gMc/GW/QoawJd2gDqQX9Yh5m4oGVI/G1qg55nDg2F2BRNsrVK6k+
GWgHcpS2/ErU8hqtABry9YqPfFbxWBTBqYUDp7bTRTgZIorFYfEDUzbOwFP+
2gDWluoDni4Eg2qTMFNxhZT7mawmETnL+DJQoqX2hxP4IVv2A1qz7Nk3HJXW
zbJXITFrcT6q5PkRVOt2Mb4hrLnjNCDQTBfEidpt9fpqIe48e2WWYIbv3bIU
4yfEGAidvdHp9tT5m+/9+qFsOVdvbfPhCK7Q37cGDtN3t9fGvpkuge28rEgD
VmgM0dP15j+F7CUJxzAISb858nXHUq2aQh6BuOLZV1cwJjj108zHsAw5hk0J
AMDSlotGIRggafi8++3Oz3zW4XR29nRi2vINMqqpzd2KwpkmlcznOFyWo05b
tWYyFsPiK6dEFTVOZjGkihNM8IKPrngwWyLOvPejN2/fnR3LXWFke9lwLHBb
+dVEvGwmBuPVLPJUR8GK69Cb/DN0I0xyc1susdE5xo0yvxRJAZAQj70ImOSz
fcXHGySTxrptPX/MLKRIFK0u8IKEjBQythN7H5chD9gVjCkrN+Zou6GJSXec
xTbEEOmg9AL5qalyZG5U43SWlUuRro4p0yikAD49G4pVF/IG5+izSxty6JJc
8KmEDnwHFaFOUXI8JsxNzZkgzIPh9sywqz6rFpoVGRgK5FYiBAoyLbLqHF2Y
pkjC04eghOgKkhGXeJlhGcmSD+OhpGjsx2SFXcM0XM1SQyzCHexxC8J7nxlc
X9aLSRF5hhHFJjuimuACCF9SiSLZEMyWUr8kjlflhiI47KqQ4CKZVS17VIgu
AytcmOfTJX2YyciSMMhR6CTjpEcbJM7vk5qFKPEdR4nEpvzbqdXm237nsNtw
FekamD7ZJdNvy15E7G6BY9XHWxPqhaxcb5HEdWbQGWfkv8GCF+sQScUwcAs+
B4s4Pl3SrKdWqFsj21nSSFUu++mgvb/PWUmD98OLJqFG3nQ7u1JS+4kbwPAO
M9f9rNBXQPe7geWfWaHuMnMyWKBlDkpw8wq4Jia78mI37xb3WZMnibMUJwXV
CgTI13ezAAppgjhoWgSRTW0iW+i3LRD/V17KcjE30KT9wEawV3jThOjOvlyh
qBMvrxe25uQqUwaoEEvPcr3IyME+FJkg6Vfr7i+3NTg8usL7G4GZ+HTreQKR
xqiE2nRa1ewQgZ7mSrKgpO1B72i5SRFEpyGZA2B8Vor7t/jw0sfEekHHtwlp
omYoxVzElMGzI0S44tm0ydvwGavtuToj7rcuzGg12Bpey9oRZTmhiDcdXj6v
Q5JqlERQk8Fd8a2L09A2Pdb1BESWZam/cq42ndc03KSQi1pKzxPENp5cYGf2
GdqSCZgiL3gUsXgEzLBa3O6G8zA6akQhSoipbv6Dq/RcLdGAc15So5OxwWGO
bJYS3rOcrNzlApXtNA3BWBAVSBQyYjPStdO/TKC/rIexAxPNCxBoU3fpqs2K
BbTaFBJUxChLho+UDY/fb4kupiuHDnDNZPillIJaY+MVFsSdsSDvN90kEGbm
ZGPBGQ46/hM9+ysrejFt/8UyRd4qumMBZOzVOGFT3bR3AABOzCpY2hAOT20o
AyIv92YjKnVdGs/GFDgFC6zqRBmpXi5gwHhBmwY+WzgKNVQkIT/jv/+vJVII
pXfN0WuDfdRHBXEZdOwEfuUMphhVdZTUAkXUhVqCx4wMgwljVzK9vWh/ODp6
gd7deuCCiG5pZje2d4a0zXy3Y6GWjszhO1oAVhrqL5Rmyy6kBA09tRKzcNKd
jVt7oJF89hyrLRwkxd1pIzPoqMDrmQ23SJZ5LVYbNjZKB3MoHxgW+SaJpnwz
ls0shp1hAHV2umQ/W0ZspC3SXOIOCEOfRvY+cjZV4sGkkVcDwl6ItxIctaFh
C4wkuHM+a2VsigXHVHadPTSYRM8ZKywmGowOUvdlwxkN1jLDeGoayfH2udn3
Bf5a2uTVw1BI+GHMUfdPRQFY4nkYYdIV7HRPy3BmhdVtDSevhdnXoEpduX3s
mXelIHhRwFRQT4eOQxunwvcxxlwiRzMSCbfXzzNzMLus2D9qd4QV4YmusPU6
zxWyJZwL0zCGkvle59ycwS3yZP9Yv74mZ8FELgegc2wrwFfRFKNNPLlJEmtt
PIlFCxR7JwqXTlt8caCyiDOC+iUqbfa8u3iqe+1/MxirSH0S1xgPRS8oXWeP
gthdgCDn8MgLydXB+WiB/ZPEMXrlzSwDjs2BbY1ZAd5plXnwIZwv596c8yTS
rAKADJeOUbiHKIkx89nG2s397Yb9sUASvJsVNGludKTHrrLMl/ZpQG56QTHn
WBZDgGSBov2HMq6iODUKF1CTQcCX0vc4Uvu6tX+wY8O0+MIWNT5+I62l0rE0
udw9PPTrHrsu94zr3kgKTCo1CUveyKbZ2/FFiQmLJs42zzr9mWS5VSU8d+J6
Ji3q1CfzKK+iO7f0BZQ7Q1qr0IipYO4UmXiuHcOY+VzV2v1GXslN407Ei15A
8QGLNcP8jOlWA/UikQ2+9bCJh0G3PLYUeN4o3g8zRAva2HoSSZ7OY3MICv0T
48BRLrfEPR0UlWVGXnMKDCjAC8VGx1vo4tcZymqZdOEDN2UfS50mT5SFHqgR
mT9jZhU4gujYx4PXHzlp9oUfN2EmHnziPzE+aE5znaBudu0xZrMqnOXR6f0b
JWNdZUm0zG2iFEX/OMEJ+koVQBsDk0jNDQpS1p8Kfbr6DC01NC4niW/M+B4W
ixmLENKkui2sslKBbJ+UjDAyxtHbUQ0OvriiY5T9Mnd0Cj8dDAieunJbluOn
XustG7mljqIsqfGsCMPIhKs8btADnXK2j+FD7pLWOtuOZspRBy99D9cDuLkv
GVXwfE0Gk+yo0rkruhoCcwjQj2KEhJXFPGxBdywNXdaOLz+ZMdOfrInQOs5B
JQA1jn1VQCJcd13wfk0ur2nAGDT+tKH3+bn9HBS+qmNmzUjOqpcMMxv0tsmP
NV+K+6BUFr1hPZKsihpfqHkv6hTHnVeJqIPs1DTOBuvTdJEHj/pMFpyrXIaW
DMPEahSoKkl6W4CZdbAwdvnlfsyHRrapRuZ71l2xWI8cEIu1lAOqxYZ/1T2C
TEcGM3E+stNxMGrim5d8Rh8LAeFZSmLf5KUbFRqMkM4w476m5bsjv+W7OLgL
gKxxT9tGAwx2iGzgkGIugQw8pOVEVc4JsrjVtkE6GPY3enN0dsaRtmUspzgY
vJaqdq1QOoAmHfDWBOFgmP2zOpaJw4KbiVVb0a4viURnBvmM36DRXXSQXHEa
LR+rAYMb76Cj5LOP7pynndkQ2/rBWupYhAxnCtj0DdRR2qYjLDyEdLQ0a8hX
B4UmdxOBHsgJq8GIIc4cesL4JgQmRB48w9Lk0Jx1+ZW6vg8yNoQRxDVj871z
xaEp8zqZTJYpMVu6xo8dB7AvyJus0zCZOtgKSbaVObRMeGu2flfJaTDY72wo
gZi7yZ3BVCwIwhwVelPYmzlnMroQd6Zjp4ULSoULNy+PT33BXMqrr3B145ol
EeAxKvJSrOWW6KkrRBj8o901xq1YED/+uLExrOfd7EkTX12ZfUNrUMfkFKC5
+4JWwXD8Df+TQP316OI13YMkPmD3d5GBU9jv8XiUE1B8n925haVWNEmBm2oe
J6ONd4Inlhq10sdGBStCSN9hPNerlPzDD0bZahpPnD28gaFLpkwEqsFqCHaN
bKwOIKA/jKDyHGzyBRomFL1hJgcNV/K1qJV0ql4OEpCnkDBlRKaXwPwJK6y+
6AqrvySMmT4y1Iy+lKxfW42I9tLKuNtog8wDvgpzecWKc4KbS75v+X1Nql6Y
4bdmL9UWr9jjYnZe6QoOytK4qXaOLY2nZIFkcIhcgv1NMjI2+6/AaJuh2Fbm
Ak/UwcVOKoLLKRDj/rA5w5MoU5DXnAJRU2ADI7rdQ47oCqFmmrTPO6J39nA0
CnYkx68fixQ4RDtWaRKS7pCfG9/NcAAAsc/Z1i4htKCajK4j9muj38jzteCf
VCmT6EV/CPBshAuF8xkm5KhPqXNyjfMKzIIkutMSdAzxvJY15fjWCthyWOsb
ca4/3ATLDBEUrRpS9/E4nM1wz4LUCOj+BMHs7j6eDkFEiFKCJy+nCWU02cP8
ktDGafheTtIA9MEpCVI5+YkPTdGQ3T06Gck1R5pezREseeIy80zckIa/gune
h9P8Rg7xuHPrwdTUtTQiRe7zBXGcUsrUBJcN8dOkJc3YU8g7jnLk8X0lWSQz
GRle6gfH/zNPvbVrZ/IrpbvSVnOkK6cjDvnkZaEQhiQ8WCtVxzckoDhFDi/H
caLODuRLR5HSS3TnRcwjUGCfEhcMydVvZDTg1SO7GZfUSFdEMA3Ot8HuWcUL
lvBNnBtmZoPLxinrbRqqPMUVYbD4FB+Lx7M6YjTkKdCfMGiaA9ArCbBbdLDc
3yTChOm4BWoegOZk5h0bsuoK8cJkicfI+TZgsMPp+LfRMEQQSYqK4/kAeizS
xuUycMkdxDHtaBOQDLPEpe74GhAdHUlyk/5XYaHilvdpoFQz01TM3N056LCf
1B1qNvWCeoddOkTjf3lgjjtz8Rv2mJqXhy1zuour2AhJIZfPbohDLrOJhlUW
5ZSyJb3whz1605QbGWhpvHAOxnTvgYvrQvjLuotmXLcniIh2HicjEgaMOOBH
yaKQ0hohzAbTcw3WwTR7HmOkW77jKTkfKLXYqzJSzQ4xqZyVULeJrbgodQNI
8xZo4zZO7uPmIiKH0Yfc4ohyvTDtO5zgMdCNjXM/ldXLcnVJVpQUCyNtoyQe
F0vE+Kd6KAWOYgva5JyEUajFFueUWS/NijZXMjdX1GF+vI4BE81kZtQztXmc
jLYM7HhHN6IMA8c3Cew7mzhgM+oTE91gCCY3huMEvEXt3UW35hTakqqTz5YR
Kg1HrFsvqDy4tEPpBSs+KaZRMJ+Q+HnDxuT5WCAFQnTB2xGFmIlTU7H4vyHb
LYZ1QDvk7BAQzyEGDQru3CR1nkLmJUaB8rcxaAuRO1xApa7aPcvM1XWSYLSK
cv8nyNL7tYFtT6gMYaHJ6+XpLpxQBSYvxn3el5I6cHnvllGsbZ4Ipn1gIAQ9
ysGUt6sg+Q6WkbwuT05jf+cAdanshpgq8mog91hSqidkZrLMPD26OKrIS0x3
dfk2F7gx5KTLmI50FAvN2VAWOvqx2Asb9V5hOeGhtRWUgrhQgwIdI/GqWkPJ
GKC02YJCAIUPpFsHsZe4y7Mjox14BckqnH+GPmE2ia3MsML4xRG9hqanaDbg
0Xl7wo6PgWUvoL9rvG2ZLp6EIZrUgjj0A+ZZhegXfVB/1itiPw+uhweerM1H
NHh9UJeGzNQDdEJVPB7Uq9Nxc3D+Dn9z6zGwKagP6q/w/6Iq+cAX82IdIlsl
yC8Stm7pcltdqPitrdzzODa9Gm/CZWTRX6wB5QXaOE2LSNJzoHGxxl0V09hb
E3oTZL8nUnsANH6AfyujVPDa6R3AMzwYcjjgD6jyShWJ2PTQND3xmpbKI9V+
udeWL4/a5S8L1ZNq1g625NEEpRJo72y+ZqyQocBFZ8k97egovJVgbhDfqqMI
jA9C4HusNXWTA9NuqL8GwW1yp0b81yANgYHAbnuvweaHBydBmAGZHgPHbKjX
IZ5weaNT1BjPlpMA2VUUqP4NqJoB19HNbmCnqNfLOViHxurFrHRNQQN3/pWs
FNDMQn3foPMpHIRGOba8FtuQPMcjqVXOk1glS5gRnX6DDhNQ2TFykwd4VB1D
NaBIxtM0UH8GAFL4M4wDTja7Dm1qokESkjFg53QwPnGlUpCZJPT8mvIMyc9H
zuVc32P2y6t0FUi8jcVesgQpcqMXIFyo4RiAPQeufxM21J8SrL8RRKCzA8r6
N3QTLKD3zRJMpTmgdJwAHzsL8Zf5fAVSYBmtPKwxgip4MWdWqFAVpjhQRitM
HGZ0DvoPf/CaKi3Rck41rGg09RfEzti3vqSS0cb/A73VRVft5gAA
</rfc> </rfc>
 End of changes. 251 change blocks. 
2298 lines changed or deleted 1034 lines changed or added

This html diff was produced by rfcdiff 1.48.