idnits 2.17.00 (12 Aug 2021) /tmp/idnits54214/draft-schmutzer-pals-ple-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (22 February 2022) is 81 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.823' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.825' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.8251' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.8261' -- Possible downref: Non-RFC (?) normative reference: ref. 'PLESIG' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 3086 ** Downref: Normative reference to an Informational RFC: RFC 3985 ** Downref: Normative reference to an Informational RFC: RFC 4197 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 4664 Summary: 6 errors (**), 0 flaws (~~), 0 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Gringeri 3 Internet-Draft J. Whittaker 4 Intended status: Standards Track Verizon 5 Expires: 26 August 2022 N. Leymann 6 Deutsche Telekom 7 C. Schmutzer, Ed. 8 L. Della Chiesa 9 N. Nainar, Ed. 10 C. Pignataro 11 Cisco Systems, Inc. 12 G. Smallegange 13 C. Brown 14 Ciena Corporation 15 F. Dada 16 Xilinx 17 22 February 2022 19 Private Line Emulation over Packet Switched Networks 20 draft-schmutzer-pals-ple-00 22 Abstract 24 This document describes a method for encapsulating high-speed bit- 25 streams as virtual private wire services (VPWS) over packet switched 26 networks (PSN) providing complete signal transport transparency. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 26 August 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction and Motivations . . . . . . . . . . . . . . . . 2 62 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 63 3. Terminology and Reference Model . . . . . . . . . . . . . . . 3 64 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Reference Models . . . . . . . . . . . . . . . . . . . . 5 66 4. PLE Encapsulation Layer . . . . . . . . . . . . . . . . . . . 6 67 4.1. PSN and VPWS Demultiplexing Headers . . . . . . . . . . . 7 68 4.2. PLE Header . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2.1. PLE Control Word . . . . . . . . . . . . . . . . . . 7 70 4.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 8 71 5. PLE Payload Layer . . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Structure Agnostic Payload . . . . . . . . . . . . . . . 10 73 5.2. Byte aligned Payload . . . . . . . . . . . . . . . . . . 11 74 5.3. 10280bit-block aligned Payload . . . . . . . . . . . . . 11 75 6. PLE Operation . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.1. Common Considerations . . . . . . . . . . . . . . . . . . 13 77 6.2. PLE IWF Operation . . . . . . . . . . . . . . . . . . . . 14 78 6.2.1. PSN-bound Encapsulation Behavior . . . . . . . . . . 14 79 6.2.2. CE-bound Decapsulation Behavior . . . . . . . . . . . 14 80 6.3. PLE Performance Monitoring . . . . . . . . . . . . . . . 16 81 6.4. QoS and Congestion Control . . . . . . . . . . . . . . . 17 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 10.2. Informative References . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction and Motivations 92 This document describes a method for encapsulating high-speed bit- 93 streams as VPWS over packet switched networks (PSN). This emulation 94 suits applications where complete signal transparency is required and 95 data interpretation of the PE would be counter productive. 97 One example is two ethernet connected CEs and the need for 98 synchronous ethernet operation between then without the intermediate 99 PEs interfering. Another example is addressing common ethernet 100 control protocol transparency concerns for carrier ethernet services, 101 beyond the behavior definitions of MEF specifications. 103 The mechanisms described in this document follow principals similar 104 to [RFC4553] but expanding the applicability beyond TDM and allow the 105 transport of signals from many technologies such as ethernet, fibre 106 channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds 107 by treating them as bit-stream payload defined in Section 3.3.3 of 108 [RFC3985]. 110 2. Requirements Notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described in BCP 115 14 [RFC2119] [RFC8174] when, and only when, they appear in all 116 capitals, as shown here. 118 3. Terminology and Reference Model 120 3.1. Terminology 122 * ACH - Associated Channel Header 124 * AIS - Alarm Indication Signal 126 * CBR - Constant Bit Rate 128 * CE - Customer Edge 130 * CSRC - Contributing SouRCe 132 * ES - Errored Second 134 * FEC - Forward Error Correction 136 * IWF - InterWorking Function 138 * LDP - Label Distribution Protocol 140 * LF - Local Fault 142 * MPLS - Multi Protocol Label Switching 144 * NSP - Native Service Processor 145 * ODUk - Optical Data Unit k 147 * OTN - Optical Transport Network 149 * OTUk - Optical Transport Unit k 151 * PCS - Physical Coding Sublayer 153 * PE - Provider Edge 155 * PLE - Private Line Emulation 157 * PLOS - Packet Loss Of Signal 159 * PSN - Packet Switched Network 161 * P2P - Point-to-Point 163 * QOS - Quality Of Service 165 * RSVP-TE - Resource Reservation Protocol Traffic Engineering 167 * RTCP - RTP Control Protocol 169 * RTP - Realtime Transport Protocol 171 * SES - Severely Errored Seconds 173 * SDH - Synchronous Digital Hierarchy 175 * SRTP - Secure Realtime Transport Protocol 177 * SRv6 - Segment Routing over IPv6 Dataplane 179 * SSRC - Synchronization SouRCe 181 * SONET - Synchronous Optical Network 183 * TCP - Transmission Control Protocol 185 * UAS - Unavailable Seconds 187 * VPWS - Virtual Private Wire Service 189 Similarly to [RFC4553] and [RFC5086] the term Interworking Function 190 (IWF) is used to describe the functional block that encapsulates bit 191 streams into PLE packets and in the reverse direction decapsulates 192 PLE packets and reconstructs bit streams. 194 3.2. Reference Models 196 The generic models defined in [RFC4664] are applicable to PLE. 198 PLE embraces the minimum intervention principle outlined in section 199 3.3.5 of [RFC3985] whereas the data is flowing through the PLE 200 encapsulation layer as received without modifications. 202 For some applications the NSP function is responsible for performing 203 operations on the native data received from the CE. Examples are 204 terminating FEC in case of 100GE or terminating the OTUk layer for 205 OTN. After the NSP the IWF is generating the payload of the VPWS 206 which carried via a PSN tunnel. 208 |<--- p2p L2VPN service -->| 209 | | 210 | |<-PSN tunnel->| | 211 v v v v 212 +---------+ +---------+ 213 | PE1 |==============| PE2 | 214 +---+-----+ +-----+---+ 215 +-----+ | N | | | | N | +-----+ 216 | CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 | 217 +-----+ ^ | P | | | | P | ^ +-----+ 218 | +---+-----+ +-----+---+ | 219 CE1 physical ^ ^ CE2 physical 220 interface | | interface 221 |<--- emulated service --->| 222 | | 223 attachment attachment 224 circuit circuit 226 Figure 1: PLE Reference Model 228 To allow the clock of the transported signal to be carried across the 229 PLE domain in a transparent way the network synchronization reference 230 model and deployment scenario outlined in section 4.3.2 of [RFC4197] 231 is applicable. 233 J 234 | G 235 v | 236 +-----+ +-----+ v 237 +-----+ |- - -|=================|- - -| +-----+ 238 | |<---------|.............................|<---------| | 239 | CE1 | | PE1 | VPWS | PE2 | | CE2 | 240 | |--------->|.............................|--------->| | 241 +-----+ |- - -|=================|- - -| +-----+ 242 ^ +-----+<-------+------->+-----+ 243 | | ^ 244 A +-+ | 245 |I| E 246 +-+ 248 Figure 2: Relative Network Scenario Timing 250 The attachment circuit clock E is generated by PE2 via a differantial 251 clock recovery method in reference to a common clock I. For this to 252 work the difference between clock I and clock A MUST be explicitly 253 transferred between the PE1 and PE2 using the timestamp inside the 254 RTP header. 256 For the reverse direction PE1 does generate the clock J in reference 257 to clock I and the clock difference between I and G. 259 The way the common clock I is implemented is out of scope of this 260 document. Well established concepts for achieving frequency 261 synchronization in a PSN have already been defined in [G.8261] and 262 can be applied here as well. 264 4. PLE Encapsulation Layer 266 The basic packet format used by PLE is shown in the Figure 3. 268 +-------------------------------+ -+ 269 | PSN and VPWS Demux | \ 270 | (MPLS/SRv6) | > PSN and VPWS 271 | | / Demux Headers 272 +-------------------------------+ -+ 273 | PLE Control Word | \ 274 +-------------------------------+ > PLE Header 275 | RTP Header | / 276 +-------------------------------+ --+ 277 | Bit Stream | \ 278 | Payload | > Payload 279 | | / 280 +-------------------------------+ --+ 281 Figure 3: PLE Encapsulation Layer 283 4.1. PSN and VPWS Demultiplexing Headers 285 This document does not imply any specific technology to be used for 286 implementing the VPWS demultiplexing and PSN layers. 288 When a MPLS PSN layer is used. A VPWS label provides the 289 demultiplexing mechanism as described in section 5.4.2 of [RFC3985]. 290 The PSN tunnel can be a simple best path Label Switched Path (LSP) 291 established using LDP [RFC5036] or Segment Routing [RFC8402] or a 292 traffic engineered LSP established using RSVP-TE [RFC3209] or SR-TE 293 [SRPOLICY]. 295 When PLE is applied to a SRv6 based PSN, the mechanisms defined in 296 [RFC8402] and the End.DX2 endpoint behavior defined in [SRV6NETPROG] 297 do apply. 299 4.2. PLE Header 301 The PLE header MUST contain the PLE control word (4 bytes) and MUST 302 include a fixed size RTP header [RFC3550]. The RTP header MUST 303 immediately follow the PLE control word. 305 4.2.1. PLE Control Word 307 The format of the PLE control word is inline with the guidance in 308 [RFC4385] and as shown in Figure 4: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 4: PLE Control Word 318 The first nibble is used to differentiate if it is a control word or 319 Associated Channel Header (ACH). The first nibble MUST be set to 320 0000b to indicate that this header is a control word as defined in 321 section 3 of [RFC4385]. 323 The other fields in the control word are used as defined below: 325 L 326 Set by the PE to indicate that data carried in the payload is 327 invalid due to an attachment circuit fault (client signal 328 failure). The downstream PE MUST play out an appropriate 329 replacement data. The NSP MAY inject an appropriate native fault 330 propagation signal. 332 R 334 Set by the downstream PE to indicate that the IWF experiences 335 packet loss from the PSN or a server layer backward fault 336 indication is present in the NSP. The R bit MUST be cleared by 337 the PE once the packet loss state or fault indication has cleared. 339 RSV 341 These bits are reserved for future use. This field MUST be set to 342 zero by the sender and ignored by the receiver. 344 FRG 346 These bits MUST be set to zero by the sender and ignored by the 347 receiver. 349 LEN 351 In accordance to [RFC4385] section 3 the length field MUST always 352 be set to zero as there is no padding added to the PLE packet. To 353 detect malformed packets the default, preconfigured or signaled 354 payload size MUST be assumed. 356 Sequence Number 358 The sequence number field is used to provide a common PW 359 sequencing function as well as detection of lost packets. It MUST 360 be generated in accordance with the rules defined in Section 5.1 361 of [RFC3550] for the RTP sequence number and MUST be incremented 362 with every PLE packet being sent. 364 4.2.2. RTP Header 366 The RTP header MUST be included and is used for explicit transfer of 367 timing information. The RTP header is purely a formal reuse and RTP 368 mechanisms, such as header extensions, contributing source (CSRC) 369 list, padding, RTP Control Protocol (RTCP), RTP header compression, 370 Secure Realtime Transport Protocol (SRTP), etc., are not applicable 371 to PLE VPWS. 373 The format of the RTP header is as shown in Figure 5: 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |V=2|P|X| CC |M| PT | Sequence Number | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Timestamp | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Synchronization Source (SSRC) Identifier | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 5: RTP Header 387 V: Version 389 The version field MUST be set to 2. 391 P: Padding 393 The padding flag MUST be set to zero by the sender and ignored by 394 the receiver. 396 X: Header Extension 398 The X bit MUST be set to zero by sender and ignored by receiver. 400 CC: CSRC Count 402 The CC field MUST be set to zero by the sender and ignored by the 403 receiver. 405 M: Marker 407 The M bit MUST be set to zero by sender and ignored by receiver. 409 PT: Payload Type 411 A PT value MUST be allocated from the range of dynamic values 412 define by [RFC3551] for each direction of the VPWS. The same PT 413 value MAY be reused both for direction and between different PLE 414 VPWS. 416 Sequence Number 417 The packet sequence number MUST continuously cycle from 0 to 418 0xFFFF. It is generated and processed in accordance with the 419 rules established in [RFC3550]. The PLE receiver MUST sequence 420 packets according to the Sequence Number field of the PLE control 421 word and MAY verify correct sequencing using RTP Sequence Number 422 field. 424 Timestamp 426 Timestamp values are used in accordance with the rules established 427 in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the 428 clock used for generating timestamps MUST be 125 MHz based on a 429 the common clock I. For bit-streams above 200 Gbps the frequency 430 MUST be 250 MHz. 432 SSRC: Synchronization Source 434 The SSRC field MAY be used for detection of misconnections. 436 5. PLE Payload Layer 438 A bit-stream is mapped into a PLE packet with a fixed payload size 439 which MUST be defined during VPWS setup, MUST be the same in both 440 directions of the VPWS and MUST remain unchanged for the lifetime of 441 the VPWS. 443 All PLE implementations MUST be capable of supporting the default 444 payload size of 1024 bytes. 446 5.1. Structure Agnostic Payload 448 The PLE payload is filled with incoming bits of the bit-stream 449 starting from the most significant to the least significant bit 450 without considering any structure of the bit-stream. 452 For PCS based attachment circuits supporting FEC the NSP function 453 MUST terminate the FEC and pass the PCS encoded signal to the IWF 454 function. 456 For PCS based attachment circuits supporting virtual lanes (i.e. 457 100GE) a PLE payload MUST carry information from all virtual lanes in 458 a bit interleaved manner after the NSP function has performed PCS 459 layer de-skew and re-ordering. 461 A PLE implementation MUST support the structure agnostic payload for 462 all bit-streams except the following: 464 * OTN 465 * 200GBASE-R ethernet 467 * 400GBASE-R ethernet 469 5.2. Byte aligned Payload 471 In case of OTN bit-streams, the NSP function MUST present to the IWF 472 an extended ODUk including a valid frame alignment overhead. The IWF 473 is performing byte-aligned mapping into PLE packets. The egress NSP 474 function will recover the ODUk by searching for the frame alignment 475 overhead. 477 For byte aligned payloads PLE uses the following order for 478 packetization: 480 * The order of the payload bytes corresponds to their order on the 481 attachment circuit. 483 * Consecutive bits coming from the attachment circuit fill each 484 payload byte starting from most significant bit to least 485 significant. 487 All PLE implementations MUST support the transport of OTN bit-streams 488 using the byte aligned payload. 490 5.3. 10280bit-block aligned Payload 492 In IEEE 802.3BS the PCS layer for 200GBASE-R and 400GBASE-R is 493 defined with the functions shown in Figure 6. 495 Reconciliation Sublayer (RS) 497 | ^ 498 v | 499 +-----------------+ +-----------------+ 500 | encode and rate | | decode and rate | 501 | matching | | matching | 502 +-----------------+ +-----------------+ 503 v ^ 504 +-----------------+ +-----------------+ 505 | 256B/257B | | reverse | 506 | transcode | | transcode | 507 +-----------------+ +-----------------+ 508 v ^ 509 +-----------------+ +-----------------+ 510 | scramble | | descramble | 511 +-----------------+ +-----------------+ 512 v ^ 513 +-----------------+ +-----------------+ 514 | alignment | | alignment | 515 | insertion | | removal | 516 +-----------------+ +-----------------+ 517 | ^ <-- IWF boundary 518 +-----------------------------------------------+ 519 | v | | 520 | +-----------------+ +-----------------+ | 521 | | pre-FEC | | post-FEC | | 522 | | distribution | | interleave | | 523 | +-----------------+ +-----------------+ | 524 | v ^ | 525 | +-----------------+ +-----------------+ | 526 | | FEC encode | | FEC decode | | 527 | +-----------------+ +-----------------+ | 528 | v ^ | 529 | +-----------------+ +-----------------+ | 530 | | distribution | | lane reorder | | 531 | | & interleave | | & de-interleave | | 532 | +-----------------+ +-----------------+ | 533 | | ^ | 534 | | +-----------------+ | 535 | | | alignment lock | | 536 | | NSP | lane deskew | | 537 | | +-----------------+ | 538 | | ^ | 539 | v | | 540 | Physical Medium Attachment (PMA) | 541 +-----------------------------------------------+ 543 Figure 6: 200GBASE-R and 400GBASE-R Functional Block Diagram 545 For 200GBASE-R and 400GBASE-R bit-streams, on ingress the NSP 546 function will perform alignment lock and lane de-skew, lane order and 547 de-interleave, FEC decode and post-FEC interleave as shown in 548 Figure 6. After the post-FEC interleave the NSP function will create 549 a stream of 10280 bit blocks (comprising of two 5140 code blocks). 551 On the egress the IWF sends a stream of 10280 bit blocks to the NSP 552 function and which performs pre-FEC distribution, FEC encode and 553 distribute and interleave functions as shown in Figure 6. 555 In the 10280 bit block stream, alignment markers exist every 4096, 556 10280 bit blocks (8192 code blocks) for 400GBASE-R and every 2048, 557 10280 bit blocks (4096 code blocks) for 200GBASE-R. 559 On ingress the NSP must indicate to the IWF when a code word carries 560 an alignment marker (or every n-th alignment marker where n is a 561 multiple of 2). The IWF will create a PLE packet with the alignment 562 marker bits at the beginning of the PLE payload. Considering the 563 default PLE payload size of 1024 bytes, the PLE payload will contain 564 the first 8096 bits (1024 bytes) of the 10280 bit block in the first 565 packet. The following PLE packets will contain the remaining bits 566 followed by the next 10280 bits. 568 The egress NSP will recover the 10280 bit block by searching for the 569 alignment markers at the beginning of PLE packets and recover the 570 10280 bit block stream. 572 For the 10280 bit data streams the NSP will use the following order 573 of packetization. 575 * The first alignment bit of a 10280 bit block is always mapped to 576 the first bit of a PLE payload 578 * The order of the bits corresponds to their order in the attached 579 circuit 581 * Consecutive bits from the attached circuit are mapped directly 582 into the PLE packet 584 With the default payload size of 1024 bytes the alignment markers 585 will be present at the start of every 5140-th PLE packet for 586 400GBASE-R and every 2570-th PLE packet for 200GBASE-R. 588 Non-default payload sizes must be chosen so that alignment markers 589 will always be at the start of every N-th packet. 591 Alignment of the signal may use the alignment marker state machine 592 defined in IEEE802.3BS. 594 6. PLE Operation 596 6.1. Common Considerations 598 A PLE VPWS can be established using manual configuration or 599 leveraging mechanisms of a signalling protocol 601 Furthermore emulation of bit-stream signals using PLE is only 602 possible when the two attachment circuits of the VPWS are of the same 603 type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE payload 604 type and payload size. This can be ensured via manual configuration 605 or via a signalling protocol 606 Extensions to the PWE3 [RFC4447] and EVPN-VPWS [RFC8214] control 607 protocols are described in a separate document [PLESIG]. 609 6.2. PLE IWF Operation 611 6.2.1. PSN-bound Encapsulation Behavior 613 After the VPWS is set up, the PSN-bound IWF does perform the 614 following steps: 616 * Packetise the data received from the CE is into a fixed size PLE 617 payloads 619 * Add PLE control word and RTP header with sequence numbers, flags 620 and timestamps properly set 622 * Add the VPWS demultiplexer and PSN headers 624 * Transmit the resulting packets over the PSN 626 * Set L bit in the PLE control word whenever attachment circuit 627 detects a fault 629 * Set R bit in the PLE control word whenever the local CE-bound IWF 630 is in packet loss state 632 6.2.2. CE-bound Decapsulation Behavior 634 The CE-bound IWF is responsible for removing the PSN and VPWS 635 demultiplexing headers, PLE control word and RTP header from the 636 received packet stream and play-out of the bit-stream to the local 637 attachment circuit. 639 A de-jitter buffer MUST be implemented where the PLE packets are 640 stored upon arrival. The size of this buffer SHOULD be locally 641 configurable to allow accommodation of specific PSN packet delay 642 variation expected. 644 The CE-bound IWF SHOULD use the sequence number in the control word 645 to detect lost and mis-ordered packets. It MAY use the sequence 646 number in the RTP header for the same purposes. 648 The payload of a lost packet MUST be replaced with equivalent amount 649 of replacement data. The contents of the replacement data MAY be 650 locally configurable. All PLE implementations MUST support 651 generation of "0xAA" as replacement data. The alternating sequence 652 of 0s and 1s of the "0xAA" pattern does ensure clock synchronization 653 is maintained. While playing out the replacement data, the IWF will 654 apply a holdover mechanism to maintain the clock. 656 Whenever the VPWS is not operationally up, the CE-bound NSP function 657 MUST inject the appropriate native downstream fault indication signal 658 (for example ODUk-AIS or ethernet LF). 660 Whenever a VPWS comes up, the CE-bound IWF enters the intermediate 661 state, will start receiving PLE packets and will store them in the 662 jitter buffer. The CE-bound NSP function will continue to inject the 663 appropriate native downstream fault indication signal until a pre- 664 configured amount of payloads is stored in the jitter buffer. 666 After the pre-configured amount of payload is present in the jitter 667 buffer the CE-bound IWF transitions to the normal operation state and 668 the content of the jitter buffer is played out to the CE in 669 accordance with the required clock. In this state the CE-bound IWF 670 MUST perform egress clock recovery. 672 The recovered clock MUST comply with the jitter and wander 673 requirements applicable to the type of attachment circuit, specified 674 in: 676 * [G.825] and [G.823] for SDH 678 * [GR253] for SONET 680 * [G.8261] for synchronous ethernet 682 * [G.8251] for OTN 684 Whenever the L bit is set in the PLE control word of a received PLE 685 packet the CE-bound NSP function SHOULD inject the appropriate native 686 downstream fault indication signal instead of playing out the 687 payload. 689 If the CE-bound IWF detects loss of consecutive packets for a pre- 690 configured amount of time (default is 1 millisecond), it enters 691 packet loss (PLOS) state and a corresponding defect is declared. 693 If the CE-bound IWF detects a packet loss ratio (PLR) above a 694 configurable signal-degrade (SD) threshold for a configurable amount 695 of consecutive 1-second intervals, it enters the degradation (DEG) 696 state and a corresponding defect is declared. Possible values for 697 the SD-PLR threshold are between 1..100% with the default being 15%. 698 Possible values for consecutive intervals are 2..10 with the default 699 7. 701 While either a PLOS or DEG defect is declared the CE-bound NSP 702 function SHOULD inject the appropriate native downstream fault 703 indication signal. Also the PSN-bound IWF SHOULD set the R bit in 704 the PLE control word of every packet transmitted. 706 The CE-bound IWF does change from the PLOS to normal state after the 707 pre-configured amount of payload has been received similarly to the 708 transition from intermediate to normal state. 710 Whenever the R bit is set in the PLE control word of a received PLE 711 packet the PLE performance monitoring statistics SHOULD get updated. 713 6.3. PLE Performance Monitoring 715 PLE SHOULD provide the following functions to monitor the network 716 performance to be inline with expectations of transport network 717 operators. 719 The near-end performance monitors defined for PLE are as follows: 721 ES-PLE : PLE Errored Seconds 723 SES-PLE : PLE Severely Errored Seconds 725 UAS-PLE : PLE Unavailable Seconds 727 Each second with at least one packet lost or a PLOS/DEG defect SHALL 728 be counted as ES-PLE. Each second with a PLR greater than 15% or a 729 PLOS/DEG defect SHALL be counted as SES-PLE. 731 UAS-PLE SHALL be counted after configurable number of consecutive 732 SES-PLE have been observed, and no longer counted after a 733 configurable number of consecutive seconds without SES-PLE have been 734 observed. Default value for each is 10 seconds. 736 Once unavailability is detected, ES and SES counts SHALL be inhibited 737 up to the point where the unavailability was started. Once 738 unavailability is removed, ES and SES that occurred along the 739 clearing period SHALL be added to the ES and SES counts. 741 A PLE far-end performance monitor is providing insight into the CE- 742 bound IWF at the far end of the PSN. The statistics are based on the 743 PLE-RDI indication carried in the PLE control word via the R bit. 745 The PLE VPWS performance monitors are derived from the definitions in 746 accordance with [G.826] 748 6.4. QoS and Congestion Control 750 The PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS 751 representing constant bit-rate (CBR) flows cannot respond to 752 congestion in a TCP-friendly manner as described in [RFC2913]. 754 Hence the PSN providing connectivity for the PLE VPWS between PE 755 devices MUST be Diffserv [RFC2475] enabled and MUST provide a per 756 domain behavior [RFC3086] that guarantees low jitter and low loss. 758 To achieve the desired per domain behavior PLE VPWS SHOULD be carried 759 over traffic-engineering paths through the PSN with bandwidth 760 reservation and admission control applied. 762 7. Security Considerations 764 As PLE is leveraging VPWS as transport mechanism the security 765 considerations described in [RFC7432] and [RFC3985] are applicable. 767 8. IANA Considerations 769 Applicable signalling extensions are out of the scope of this 770 document. 772 PLE does not introduce additional requirements from IANA. 774 9. Acknowledgements 776 The authors would like to thank Andreas Burk for reviewing this 777 document and providing useful comments and suggestions. 779 10. References 781 10.1. Normative References 783 [G.823] International Telecommunication Union (ITU), "G.823: The 784 control of jitter and wander within digital networks which 785 are based on the 2048 kbit/s hierarchy", 786 . 788 [G.825] International Telecommunication Union (ITU), "G.825: The 789 control of jitter and wander within digital networks which 790 are based on the synchronous digital hierarchy (SDH)", 791 . 793 [G.8251] International Telecommunication Union (ITU), "G.8251: The 794 control of jitter and wander within the optical transport 795 network (OTN)", . 797 [G.8261] International Telecommunication Union (ITU), "G.8261: 798 Timing and synchronization aspects in packet networks", 799 . 801 [PLESIG] IETF, "Private Line Emulation VPWS Signalling", 802 . 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, 807 DOI 10.17487/RFC2119, March 1997, 808 . 810 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 811 and W. Weiss, "An Architecture for Differentiated 812 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 813 . 815 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 816 Differentiated Services Per Domain Behaviors and Rules for 817 their Specification", RFC 3086, DOI 10.17487/RFC3086, 818 April 2001, . 820 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 821 Jacobson, "RTP: A Transport Protocol for Real-Time 822 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 823 July 2003, . 825 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 826 Video Conferences with Minimal Control", STD 65, RFC 3551, 827 DOI 10.17487/RFC3551, July 2003, 828 . 830 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 831 Edge-to-Edge (PWE3) Architecture", RFC 3985, 832 DOI 10.17487/RFC3985, March 2005, 833 . 835 [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation 836 of Time Division Multiplexed (TDM) Circuits over Packet 837 Switching Networks", RFC 4197, DOI 10.17487/RFC4197, 838 October 2005, . 840 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 841 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 842 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 843 February 2006, . 845 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 846 G. Heron, "Pseudowire Setup and Maintenance Using the 847 Label Distribution Protocol (LDP)", RFC 4447, 848 DOI 10.17487/RFC4447, April 2006, 849 . 851 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 852 2 Virtual Private Networks (L2VPNs)", RFC 4664, 853 DOI 10.17487/RFC4664, September 2006, 854 . 856 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 857 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 858 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 859 2015, . 861 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 862 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 863 May 2017, . 865 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 866 Rabadan, "Virtual Private Wire Service Support in Ethernet 867 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 868 . 870 10.2. Informative References 872 [G.707] ITU-T, "Network node interface for the synchronous digital 873 hierarchy (SDH)", . 875 [G.709] International Telecommunication Union (ITU), "G.709: 876 Interfaces for the optical transport network", 877 . 879 [G.826] ITU-T, "End-to-end error performance parameters and 880 objectives for international, constant bit-rate digital 881 paths and connections", 882 . 884 [GR253] Telcordia, "SONET Transport Systems : Common Generic 885 Criteria", . 887 [RFC2913] Klyne, G., "MIME Content Types in Media Feature 888 Expressions", RFC 2913, DOI 10.17487/RFC2913, September 889 2000, . 891 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 892 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 893 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 894 . 896 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 897 Agnostic Time Division Multiplexing (TDM) over Packet 898 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 899 . 901 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 902 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 903 October 2007, . 905 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 906 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 907 Circuit Emulation Service over Packet Switched Network 908 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 909 . 911 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 912 Decraene, B., Litkowski, S., and R. Shakir, "Segment 913 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 914 July 2018, . 916 [SRPOLICY] IETF, "Segment Routing Policy Architecture", 917 . 920 [SRV6NETPROG] 921 IETF, "SRv6 Network Programming", 922 . 925 Authors' Addresses 927 Steven Gringeri 928 Verizon 929 Email: steven.gringeri@verizon.com 931 Jeremy Whittaker 932 Verizon 933 Email: jeremy.whittaker@verizon.com 934 Nicolai Leymann 935 Deutsche Telekom 936 Email: N.Leymann@telekom.de 938 Christian Schmutzer (editor) 939 Cisco Systems, Inc. 940 Email: cschmutz@cisco.com 942 Luca Della Chiesa 943 Cisco Systems, Inc. 944 Email: ldellach@cisco.com 946 Nagendra Kumar Nainar (editor) 947 Cisco Systems, Inc. 948 Email: naikumar@cisco.com 950 Carlos Pignataro 951 Cisco Systems, Inc. 952 Email: cpignata@cisco.com 954 Gerald Smallegange 955 Ciena Corporation 956 Email: gsmalleg@ciena.com 958 Chris Brown 959 Ciena Corporation 960 Email: cbrown@ciena.com 962 Faisal Dada 963 Xilinx 964 Email: faisald@xilinx.com