idnits 2.17.1 draft-schmutzer-bess-ple-03.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (17 August 2021) is 983 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 (~~), 1 warning (==), 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: 18 February 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 17 August 2021 19 Private Line Emulation over Packet Switched Networks 20 draft-schmutzer-bess-ple-03 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 18 February 2022. 45 Copyright Notice 47 Copyright (c) 2021 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 Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified 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. Constant Bit Rate Payload . . . . . . . . . . . . . . . . 10 73 5.2. Byte aligned Payload . . . . . . . . . . . . . . . . . . 11 74 6. PLE Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 76 6.2. PLE IWF Operation . . . . . . . . . . . . . . . . . . . . 11 77 6.2.1. PSN-bound Encapsulation Behavior . . . . . . . . . . 11 78 6.2.2. CE-bound Decapsulation Behavior . . . . . . . . . . . 12 79 6.3. PLE Performance Monitoring . . . . . . . . . . . . . . . 14 80 6.4. QoS and Congestion Control . . . . . . . . . . . . . . . 14 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 10.2. Informative References . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction and Motivations 91 This document describes a method for encapsulating high-speed bit- 92 streams as VPWS over packet switched networks (PSN). This emulation 93 suits applications where complete signal transparency is required and 94 data interpretation of the PE would be counter productive. 96 One example is two ethernet connected CEs and the need for 97 synchronous ethernet operation between then without the intermediate 98 PEs interfering. Another example is addressing common ethernet 99 control protocol transparency concerns for carrier ethernet services, 100 beyond the behavior definitions of MEF specifications. 102 The mechanisms described in this document follow principals similar 103 to [RFC4553] but expanding the applicability beyond TDM and allow the 104 transport of signals from many technologies such as ethernet, fibre 105 channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds 106 by treating them as bit-stream payload defined in Section 3.3.3 of 107 [RFC3985]. 109 2. Requirements Notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. Terminology and Reference Model 119 3.1. Terminology 121 * ACH - Associated Channel Header 123 * AIS - Alarm Indication Signal 125 * CBR - Constant Bit Rate 127 * CE - Customer Edge 129 * CSRC - Contributing SouRCe 131 * ES - Errored Second 133 * FEC - Forward Error Correction 135 * IWF - InterWorking Function 137 * LDP - Label Distribution Protocol 139 * LF - Local Fault 141 * MPLS - Multi Protocol Label Switching 143 * NSP - Native Service Processor 144 * ODUk - Optical Data Unit k 146 * OTN - Optical Transport Network 148 * OTUk - Optical Transport Unit k 150 * PCS - Physical Coding Sublayer 152 * PE - Provider Edge 154 * PLE - Private Line Emulation 156 * PLOS - Packet Loss Of Signal 158 * PSN - Packet Switched Network 160 * P2P - Point-to-Point 162 * QOS - Quality Of Service 164 * RSVP-TE - Resource Reservation Protocol Traffic Engineering 166 * RTCP - RTP Control Protocol 168 * RTP - Realtime Transport Protocol 170 * SES - Severely Errored Seconds 172 * SDH - Synchronous Digital Hierarchy 174 * SRTP - Secure Realtime Transport Protocol 176 * SRv6 - Segment Routing over IPv6 Dataplane 178 * SSRC - Synchronization SouRCe 180 * SONET - Synchronous Optical Network 182 * TCP - Transmission Control Protocol 184 * UAS - Unavailable Seconds 186 * VPWS - Virtual Private Wire Service 188 Similarly to [RFC4553] and [RFC5086] the term Interworking Function 189 (IWF) is used to describe the functional block that encapsulates bit 190 streams into PLE packets and in the reverse direction decapsulates 191 PLE packets and reconstructs bit streams. 193 3.2. Reference Models 195 The generic models defined in [RFC4664] are applicable to PLE. 197 PLE embraces the minimum intervention principle outlined in section 198 3.3.5 of [RFC3985] whereas the data is flowing through the PLE 199 encapsulation layer as received without modifications. 201 For some applications the NSP function is responsible for performing 202 operations on the native data received from the CE. Examples are 203 terminating FEC in case of 100GE or terminating the OTUk layer for 204 OTN. After the NSP the IWF is generating the payload of the VPWS 205 which carried via a PSN tunnel. 207 |<--- p2p L2VPN service -->| 208 | | 209 | |<-PSN tunnel->| | 210 v v v v 211 +---------+ +---------+ 212 | PE1 |==============| PE2 | 213 +---+-----+ +-----+---+ 214 +-----+ | N | | | | N | +-----+ 215 | CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 | 216 +-----+ ^ | P | | | | P | ^ +-----+ 217 | +---+-----+ +-----+---+ | 218 CE1 physical ^ ^ CE2 physical 219 interface | | interface 220 |<--- emulated service --->| 221 | | 222 attachment attachment 223 circuit circuit 225 Figure 1: PLE Reference Model 227 To allow the clock of the transported signal to be carried across the 228 PLE domain in a transparent way the network synchronization reference 229 model and deployment scenario outlined in section 4.3.2 of [RFC4197] 230 is applicable. 232 J 233 | G 234 v | 235 +-----+ +-----+ v 236 +-----+ |- - -|=================|- - -| +-----+ 237 | |<---------|.............................|<---------| | 238 | CE1 | | PE1 | VPWS | PE2 | | CE2 | 239 | |--------->|.............................|--------->| | 240 +-----+ |- - -|=================|- - -| +-----+ 241 ^ +-----+<-------+------->+-----+ 242 | | ^ 243 A +-+ | 244 |I| E 245 +-+ 247 Figure 2: Relative Network Scenario Timing 249 The attachment circuit clock E is generated by PE2 via a differantial 250 clock recovery method in reference to a common clock I. For this to 251 work the difference between clock I and clock A MUST be explicitly 252 transferred between the PE1 and PE2 using the timestamp inside the 253 RTP header. 255 For the reverse direction PE1 does generate the clock J in reference 256 to clock I and the clock difference between I and G. 258 The way the common clock I is implemented is out of scope of this 259 document. Well established concepts for achieving frequency 260 synchronization in a PSN have already been defined in [G.8261] and 261 can be applied here as well. 263 4. PLE Encapsulation Layer 265 The basic packet format used by PLE is shown in the below figure. 267 +-------------------------------+ -+ 268 | PSN and VPWS Demux | \ 269 | (MPLS/SRv6) | > PSN and VPWS 270 | | / Demux Headers 271 +-------------------------------+ -+ 272 | PLE Control Word | \ 273 +-------------------------------+ > PLE Header 274 | RTP Header | / 275 +-------------------------------+ --+ 276 | Bit Stream | \ 277 | Payload | > Payload 278 | | / 279 +-------------------------------+ --+ 280 Figure 3: PLE Encapsulation Layer 282 4.1. PSN and VPWS Demultiplexing Headers 284 This document does not imply any specific technology to be used for 285 implementing the VPWS demultiplexing and PSN layers. 287 When a MPLS PSN layer is used. A VPWS label provides the 288 demultiplexing mechanism as described in section 5.4.2 of [RFC3985]. 289 The PSN tunnel can be a simple best path Label Switched Path (LSP) 290 established using LDP [RFC5036] or Segment Routing [RFC8402] or a 291 traffic engineered LSP established using RSVP-TE [RFC3209] or SR-TE 292 [SRPOLICY]. 294 When PLE is applied to a SRv6 based PSN, the mechanisms defined in 295 [RFC8402] and the End.DX2 endpoint behavior defined in [SRV6NETPROG] 296 do apply. 298 4.2. PLE Header 300 The PLE header MUST contain the PLE control word (4 bytes) and MUST 301 include a fixed size RTP header [RFC3550]. The RTP header MUST 302 immediately follow the PLE control word. 304 4.2.1. PLE Control Word 306 The format of the PLE control word is inline with the guidance in 307 [RFC4385] and as shown in the below figure: 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 4: PLE Control Word 317 The first nibble is used to differentiate if it is a control word or 318 Associated Channel Header (ACH). The first nibble MUST be set to 319 0000b to indicate that this header is a control word as defined in 320 section 3 of [RFC4385]. 322 The other fields in the control word are used as defined below: 324 L 325 Set by the PE to indicate that data carried in the payload is 326 invalid due to an attachment circuit fault (client signal 327 failure). The downstream PE MUST play out an appropriate 328 replacement data. The NSP MAY inject an appropriate native fault 329 propagation signal. 331 R 333 Set by the downstream PE to indicate that the IWF experiences 334 packet loss from the PSN or a server layer backward fault 335 indication is present in the NSP. The R bit MUST be cleared by 336 the PE once the packet loss state or fault indication has cleared. 338 RSV 340 These bits are reserved for future use. This field MUST be set to 341 zero by the sender and ignored by the receiver. 343 FRG 345 These bits MUST be set to zero by the sender and ignored by the 346 receiver. 348 LEN 350 In accordance to [RFC4385] section 3 the length field MUST always 351 be set to zero as there is no padding added to the PLE packet. To 352 detect malformed packets the default, preconfigured or signaled 353 payload size MUST be assumed. 355 Sequence Number 357 The sequence number field is used to provide a common PW 358 sequencing function as well as detection of lost packets. It MUST 359 be generated in accordance with the rules defined in Section 5.1 360 of [RFC3550] for the RTP sequence number and MUST be incremented 361 with every PLE packet being sent. 363 4.2.2. RTP Header 365 The RTP header MUST be included and is used for explicit transfer of 366 timing information. The RTP header is purely a formal reuse and RTP 367 mechanisms, such as header extensions, contributing source (CSRC) 368 list, padding, RTP Control Protocol (RTCP), RTP header compression, 369 Secure Realtime Transport Protocol (SRTP), etc., are not applicable 370 to PLE VPWS. 372 The format of the RTP header is as shown in the below figure: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |V=2|P|X| CC |M| PT | Sequence Number | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Timestamp | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Synchronization Source (SSRC) Identifier | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 5: RTP Header 386 V: Version 388 The version field MUST be set to 2. 390 P: Padding 392 The padding flag MUST be set to zero by the sender and ignored by 393 the receiver. 395 X: Header Extension 397 The X bit MUST be set to zero by sender and ignored by receiver. 399 CC: CSRC Count 401 The CC field MUST be set to zero by the sender and ignored by the 402 receiver. 404 M: Marker 406 The M bit MUST be set to zero by sender and ignored by receiver. 408 PT: Payload Type 410 A PT value MUST be allocated from the range of dynamic values 411 define by [RFC3551] for each direction of the VPWS. The same PT 412 value MAY be reused both for direction and between different PLE 413 VPWS. 415 Sequence Number 416 The packet sequence number MUST continuously cycle from 0 to 417 0xFFFF. It is generated and processed in accordance with the 418 rules established in [RFC3550]. The PLE receiver MUST sequence 419 packets according to the Sequence Number field of the PLE control 420 word and MAY verify correct sequencing using RTP Sequence Number 421 field. 423 Timestamp 425 Timestamp values are used in accordance with the rules established 426 in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the 427 clock used for generating timestamps MUST be 125 MHz based on a 428 the common clock I. For bit-streams above 200 Gbps the frequency 429 MUST be 250 MHz. 431 SSRC: Synchronization Source 433 The SSRC field MAY be used for detection of misconnections. 435 5. PLE Payload Layer 437 5.1. Constant Bit Rate Payload 439 A bit-stream is mapped into a packet with a fixed payload size 440 ignoring any structure being present. The number of bytes MUST be 441 defined during VPWS setup, MUST be the same in both directions of the 442 VPWS and MUST remain unchanged for the lifetime of the VPWS. 444 For constant bit rate payloads the PLE packet is filled with incoming 445 bits of the bit stream starting from the most significant to the 446 least significant bit. 448 All PLE implementations MUST be capable of supporting the default 449 payload size of 1024 bytes. 451 For PCS based CE interface types supporting FEC the NSP function MUST 452 terminate the FEC and pass the PCS encoded signal to the IWF 453 function. 455 For PCS based CE interface types supporting virtual lanes (i.e. 456 100GE) a PLE payload MUST carry information from all virtual lanes in 457 a bit interleaved manner after the NSP function has performed PCS 458 layer de-skew and re-ordering. 460 A PLE implementation MUST support the transport of all service types 461 except ODUk bit-streams using the constant bit rate payload. 463 5.2. Byte aligned Payload 465 In case of an OTN bit-stream, the NSP function MUST present to the 466 IWF an extended ODUk including a valid frame alignment overhead. The 467 IWF is performing byte-aligned mapping into PLE packets. The egress 468 NSP function will recover the ODUk by searching for the frame 469 alignment overhead. 471 For byte aligned payloads PLE uses the following order for 472 packetization: 474 * The order of the payload bytes corresponds to their order on the 475 attachment circuit. 477 * Consecutive bits coming from the attachment circuit fill each 478 payload byte starting from most significant bit to least 479 significant. 481 All PLE implementations MUST support the payload size of 1024 bytes. 483 All PLE implementations MUST support the transport of OTN bit-streams 484 using the byte aligned payload. 486 6. PLE Operation 488 6.1. Common Considerations 490 A PLE VPWS can be established using manual configuration or 491 leveraging mechanisms of a signalling protocol 493 Furthermore emulation of bit-stream signals using PLE is only 494 possible when the two attachment circuits of the VPWS are of the same 495 type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE payload 496 type and payload size. This can be ensured via manual configuration 497 or via a signalling protocol 499 Extensions to the PWE3 [RFC4447] and EVPN-VPWS [RFC8214] control 500 protocols are described in a separate document [PLESIG]. 502 6.2. PLE IWF Operation 504 6.2.1. PSN-bound Encapsulation Behavior 506 After the VPWS is set up, the PSN-bound IWF does perform the 507 following steps: 509 * Packetise the data received from the CE is into a fixed size PLE 510 payloads 512 * Add PLE control word and RTP header with sequence numbers, flags 513 and timestamps properly set 515 * Add the VPWS demultiplexer and PSN headers 517 * Transmit the resulting packets over the PSN 519 * Set L bit in the PLE control word whenever attachment circuit 520 detects a fault 522 * Set R bit in the PLE control word whenever the local CE-bound IWF 523 is in packet loss state 525 6.2.2. CE-bound Decapsulation Behavior 527 The CE-bound IWF is responsible for removing the PSN and VPWS 528 demultiplexing headers, PLE control word and RTP header from the 529 received packet stream and play-out of the bit-stream to the local 530 attachment circuit. 532 A de-jitter buffer MUST be implemented where the PLE packets are 533 stored upon arrival. The size of this buffer SHOULD be locally 534 configurable to allow accommodation of specific PSN packet delay 535 variation expected. 537 The CE-bound IWF SHOULD use the sequence number in the control word 538 to detect lost and mis-ordered packets. It MAY use the sequence 539 number in the RTP header for the same purposes. 541 The payload of a lost packet MUST be replaced with equivalent amount 542 of replacement data. The contents of the replacement data MAY be 543 locally configurable. All PLE implementations MUST support 544 generation of "0xAA" as replacement data. The alternating sequence 545 of 0s and 1s of the "0xAA" pattern does ensure clock synchronization 546 is maintained. While playing out the replacement data, the IWF will 547 apply a holdover mechanism to maintain the clock. 549 Whenever the VPWS is not operationally up, the CE-bound NSP function 550 MUST inject the appropriate native downstream fault indication signal 551 (for example ODUk-AIS or ethernet LF). 553 Whenever a VPWS comes up, the CE-bound IWF enters the intermediate 554 state, will start receiving PLE packets and will store them in the 555 jitter buffer. The CE-bound NSP function will continue to inject the 556 appropriate native downstream fault indication signal until a pre- 557 configured amount of payloads is stored in the jitter buffer. 559 After the pre-configured amount of payload is present in the jitter 560 buffer the CE-bound IWF transitions to the normal operation state and 561 the content of the jitter buffer is played out to the CE in 562 accordance with the required clock. In this state the CE-bound IWF 563 MUST perform egress clock recovery. 565 The recovered clock MUST comply with the jitter and wander 566 requirements applicable to the type of attachment circuit, specified 567 in: 569 * [G.825] and [G.823] for SDH 571 * [GR253] for SONET 573 * [G.8261] for synchronous ethernet 575 * [G.8251] for OTN 577 Whenever the L bit is set in the PLE control word of a received PLE 578 packet the CE-bound NSP function SHOULD inject the appropriate native 579 downstream fault indication signal instead of playing out the 580 payload. 582 If the CE-bound IWF detects loss of consecutive packets for a pre- 583 configured amount of time (default is 1 millisecond), it enters 584 packet loss (PLOS) state and a corresponding defect is declared. 586 If the CE-bound IWF detects a packet loss ratio (PLR) above a 587 configurable signal-degrade (SD) threshold for a configurable amount 588 of consecutive 1-second intervals, it enters the degradation (DEG) 589 state and a corresponding defect is declared. Possible values for 590 the SD-PLR threshold are between 1..100% with the default being 15%. 591 Possible values for consecutive intervals are 2..10 with the default 592 7. 594 While either a PLOS or DEG defect is declared the CE-bound NSP 595 function SHOULD inject the appropriate native downstream fault 596 indication signal. Also the PSN-bound IWF SHOULD set the R bit in 597 the PLE control word of every packet transmitted. 599 The CE-bound IWF does change from the PLOS to normal state after the 600 pre-configured amount of payload has been received similarly to the 601 transition from intermediate to normal state. 603 Whenever the R bit is set in the PLE control word of a received PLE 604 packet the PLE performance monitoring statistics SHOULD get updated. 606 6.3. PLE Performance Monitoring 608 PLE SHOULD provide the following functions to monitor the network 609 performance to be inline with expectations of transport network 610 operators. 612 The near-end performance monitors defined for PLE are as follows: 614 ES-PLE : PLE Errored Seconds 616 SES-PLE : PLE Severely Errored Seconds 618 UAS-PLE : PLE Unavailable Seconds 620 Each second with at least one packet lost or a PLOS/DEG defect SHALL 621 be counted as ES-PLE. Each second with a PLR greater than 15% or a 622 PLOS/DEG defect SHALL be counted as SES-PLE. 624 UAS-PLE SHALL be counted after configurable number of consecutive 625 SES-PLE have been observed, and no longer counted after a 626 configurable number of consecutive seconds without SES-PLE have been 627 observed. Default value for each is 10 seconds. 629 Once unavailability is detected, ES and SES counts SHALL be inhibited 630 up to the point where the unavailability was started. Once 631 unavailability is removed, ES and SES that occurred along the 632 clearing period SHALL be added to the ES and SES counts. 634 A PLE far-end performance monitor is providing insight into the CE- 635 bound IWF at the far end of the PSN. The statistics are based on the 636 PLE-RDI indication carried in the PLE control word via the R bit. 638 The PLE VPWS performance monitors are derived from the definitions in 639 accordance with [G.826] 641 6.4. QoS and Congestion Control 643 The PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS 644 representing constant bit-rate (CBR) flows cannot respond to 645 congestion in a TCP-friendly manner as described in [RFC2913]. 647 Hence the PSN providing connectivity for the PLE VPWS between PE 648 devices MUST be Diffserv [RFC2475] enabled and MUST provide a per 649 domain behavior [RFC3086] that guarantees low jitter and low loss. 651 To achieve the desired per domain behavior PLE VPWS SHOULD be carried 652 over traffic-engineering paths through the PSN with bandwidth 653 reservation and admission control applied. 655 7. Security Considerations 657 As PLE is leveraging VPWS as transport mechanism the security 658 considerations described in [RFC7432] and [RFC3985] are applicable. 660 8. IANA Considerations 662 Applicable signalling extensions are out of the scope of this 663 document. 665 PLE does not introduce additional requirements from IANA. 667 9. Acknowledgements 669 The authors would like to thank Andreas Burk for reviewing this 670 document and providing useful comments and suggestions. 672 10. References 674 10.1. Normative References 676 [G.823] International Telecommunication Union (ITU), "G.823: The 677 control of jitter and wander within digital networks which 678 are based on the 2048 kbit/s hierarchy", 679 . 681 [G.825] International Telecommunication Union (ITU), "G.825: The 682 control of jitter and wander within digital networks which 683 are based on the synchronous digital hierarchy (SDH)", 684 . 686 [G.8251] International Telecommunication Union (ITU), "G.8251: The 687 control of jitter and wander within the optical transport 688 network (OTN)", . 690 [G.8261] International Telecommunication Union (ITU), "G.8261: 691 Timing and synchronization aspects in packet networks", 692 . 694 [PLESIG] IETF, "Private Line Emulation VPWS Signalling", 695 . 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, 700 DOI 10.17487/RFC2119, March 1997, 701 . 703 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 704 and W. Weiss, "An Architecture for Differentiated 705 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 706 . 708 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 709 Differentiated Services Per Domain Behaviors and Rules for 710 their Specification", RFC 3086, DOI 10.17487/RFC3086, 711 April 2001, . 713 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 714 Jacobson, "RTP: A Transport Protocol for Real-Time 715 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 716 July 2003, . 718 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 719 Video Conferences with Minimal Control", STD 65, RFC 3551, 720 DOI 10.17487/RFC3551, July 2003, 721 . 723 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 724 Edge-to-Edge (PWE3) Architecture", RFC 3985, 725 DOI 10.17487/RFC3985, March 2005, 726 . 728 [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation 729 of Time Division Multiplexed (TDM) Circuits over Packet 730 Switching Networks", RFC 4197, DOI 10.17487/RFC4197, 731 October 2005, . 733 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 734 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 735 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 736 February 2006, . 738 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 739 G. Heron, "Pseudowire Setup and Maintenance Using the 740 Label Distribution Protocol (LDP)", RFC 4447, 741 DOI 10.17487/RFC4447, April 2006, 742 . 744 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 745 2 Virtual Private Networks (L2VPNs)", RFC 4664, 746 DOI 10.17487/RFC4664, September 2006, 747 . 749 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 750 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 751 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 752 2015, . 754 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 755 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 756 May 2017, . 758 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 759 Rabadan, "Virtual Private Wire Service Support in Ethernet 760 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 761 . 763 10.2. Informative References 765 [G.707] ITU-T, "Network node interface for the synchronous digital 766 hierarchy (SDH)", . 768 [G.709] International Telecommunication Union (ITU), "G.709: 769 Interfaces for the optical transport network", 770 . 772 [G.826] ITU-T, "End-to-end error performance parameters and 773 objectives for international, constant bit-rate digital 774 paths and connections", 775 . 777 [GR253] Telcordia, "SONET Transport Systems : Common Generic 778 Criteria", . 780 [RFC2913] Klyne, G., "MIME Content Types in Media Feature 781 Expressions", RFC 2913, DOI 10.17487/RFC2913, September 782 2000, . 784 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 785 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 786 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 787 . 789 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 790 Agnostic Time Division Multiplexing (TDM) over Packet 791 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 792 . 794 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 795 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 796 October 2007, . 798 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 799 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 800 Circuit Emulation Service over Packet Switched Network 801 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 802 . 804 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 805 Decraene, B., Litkowski, S., and R. Shakir, "Segment 806 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 807 July 2018, . 809 [SRPOLICY] IETF, "Segment Routing Policy Architecture", 810 . 813 [SRV6NETPROG] 814 IETF, "SRv6 Network Programming", 815 . 818 Authors' Addresses 820 Steven Gringeri 821 Verizon 823 Email: steven.gringeri@verizon.com 825 Jeremy Whittaker 826 Verizon 828 Email: jeremy.whittaker@verizon.com 830 Nicolai Leymann 831 Deutsche Telekom 833 Email: N.Leymann@telekom.de 835 Christian Schmutzer (editor) 836 Cisco Systems, Inc. 838 Email: cschmutz@cisco.com 839 Luca Della Chiesa 840 Cisco Systems, Inc. 842 Email: ldellach@cisco.com 844 Nagendra Kumar Nainar (editor) 845 Cisco Systems, Inc. 847 Email: naikumar@cisco.com 849 Carlos Pignataro 850 Cisco Systems, Inc. 852 Email: cpignata@cisco.com 854 Gerald Smallegange 855 Ciena Corporation 857 Email: gsmalleg@ciena.com 859 Chris Brown 860 Ciena Corporation 862 Email: cbrown@ciena.com 864 Faisal Dada 865 Xilinx 867 Email: faisald@xilinx.com