idnits 2.17.1 draft-schmutzer-bess-ple-02.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 (February 22, 2021) is 1158 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: August 26, 2021 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 February 22, 2021 19 Private Line Emulation over Packet Switched Networks 20 draft-schmutzer-bess-ple-02 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 August 26, 2021. 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 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction and Motivations . . . . . . . . . . . . . . . . 3 63 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 64 3. Terminology and Reference Model . . . . . . . . . . . . . . . 3 65 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.2. Reference Models . . . . . . . . . . . . . . . . . . . . 5 67 4. PLE Encapsulation Layer . . . . . . . . . . . . . . . . . . . 6 68 4.1. PSN and VPWS Demultiplexing Headers . . . . . . . . . . . 7 69 4.2. PLE Header . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2.1. PLE Control Word . . . . . . . . . . . . . . . . . . 7 71 4.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 9 72 5. PLE Payload Layer . . . . . . . . . . . . . . . . . . . . . . 10 73 5.1. Constant Bit Rate Payload . . . . . . . . . . . . . . . . 10 74 5.2. Byte aligned Payload . . . . . . . . . . . . . . . . . . 11 75 6. PLE Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 77 6.2. PLE IWF Operation . . . . . . . . . . . . . . . . . . . . 12 78 6.2.1. PSN-bound Encapsulation Behavior . . . . . . . . . . 12 79 6.2.2. CE-bound Decapsulation Behavior . . . . . . . . . . . 12 80 6.3. PLE Performance Monitoring . . . . . . . . . . . . . . . 14 81 6.4. QoS and Congestion Control . . . . . . . . . . . . . . . 15 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 87 10.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 o ACH - Associated Channel Header 124 o AIS - Alarm Indication Signal 126 o CBR - Constant Bit Rate 128 o CE - Customer Edge 130 o CSRC - Contributing SouRCe 132 o ES - Errored Second 134 o FEC - Forward Error Correction 136 o IWF - InterWorking Function 137 o LDP - Label Distribution Protocol 139 o LF - Local Fault 141 o MPLS - Multi Protocol Label Switching 143 o NSP - Native Service Processor 145 o ODUk - Optical Data Unit k 147 o OTN - Optical Transport Network 149 o OTUk - Optical Transport Unit k 151 o PCS - Physical Coding Sublayer 153 o PE - Provider Edge 155 o PLE - Private Line Emulation 157 o PLOS - Packet Loss Of Signal 159 o PSN - Packet Switched Network 161 o P2P - Point-to-Point 163 o QOS - Quality Of Service 165 o RSVP-TE - Resource Reservation Protocol Traffic Engineering 167 o RTCP - RTP Control Protocol 169 o RTP - Realtime Transport Protocol 171 o SES - Severely Errored Seconds 173 o SDH - Synchronous Digital Hierarchy 175 o SRTP - Secure Realtime Transport Protocol 177 o SRv6 - Segment Routing over IPv6 Dataplane 179 o SSRC - Synchronization SouRCe 181 o SONET - Synchronous Optical Network 183 o TCP - Transmission Control Protocol 184 o UAS - Unavailable Seconds 186 o 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 +-------------------------------+ --+ 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 the below figure: 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 327 Set by the PE to indicate that data carried in the payload is 328 invalid due to an attachment circuit fault (client signal 329 failure). The downstream PE MUST play out an appropriate 330 replacement data. The NSP MAY inject an appropriate native fault 331 propagation signal. 333 R 335 Set by the downstream PE to indicate that the IWF experiences 336 packet loss from the PSN or a server layer backward fault 337 indication is present in the NSP. The R bit MUST be cleared by 338 the PE once the packet loss state or fault indication has cleared. 340 RSV 342 These bits are reserved for future use. This field MUST be set to 343 zero by the sender and ignored by the receiver. 345 FRG 347 These bits MUST be set to zero by the sender and ignored by the 348 receiver. 350 LEN 352 In accordance to [RFC4385] section 3 the length field MUST always 353 be set to zero as there is no padding added to the PLE packet. To 354 detect malformed packets the default, preconfigured or signaled 355 payload size MUST be assumed. 357 Sequence Number 359 The sequence number field is used to provide a common PW 360 sequencing function as well as detection of lost packets. It MUST 361 be generated in accordance with the rules defined in Section 5.1 362 of [RFC3550] for the RTP sequence number and MUST be incremented 363 with every PLE packet being sent. 365 4.2.2. RTP Header 367 The RTP header MUST be included and is used for explicit transfer of 368 timing information. The RTP header is purely a formal reuse and RTP 369 mechanisms, such as header extensions, contributing source (CSRC) 370 list, padding, RTP Control Protocol (RTCP), RTP header compression, 371 Secure Realtime Transport Protocol (SRTP), etc., are not applicable 372 to PLE VPWS. 374 The format of the RTP header is as shown in the below figure: 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |V=2|P|X| CC |M| PT | Sequence Number | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Timestamp | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Synchronization Source (SSRC) Identifier | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 5: RTP Header 388 V: Version 390 The version field MUST be set to 2. 392 P: Padding 394 The padding flag MUST be set to zero by the sender and ignored by 395 the receiver. 397 X: Header Extension 399 The X bit MUST be set to zero by sender and ignored by receiver. 401 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 418 The packet sequence number MUST continuously cycle from 0 to 419 0xFFFF. It is generated and processed in accordance with the 420 rules established in [RFC3550]. The PLE receiver MUST sequence 421 packets according to the Sequence Number field of the PLE control 422 word and MAY verify correct sequencing using RTP Sequence Number 423 field. 425 Timestamp 427 Timestamp values are used in accordance with the rules established 428 in [RFC3550]. For bit-streams up to 200 Gbps the frequency of the 429 clock used for generating timestamps MUST be 125 MHz based on a 430 the common clock I. For bit-streams above 200 Gbps the frequency 431 MUST be 250 MHz. 433 SSRC: Synchronization Source 435 The SSRC field MAY be used for detection of misconnections. 437 5. PLE Payload Layer 439 5.1. Constant Bit Rate Payload 441 A bit-stream is mapped into a packet with a fixed payload size 442 ignoring any structure being present. The number of bytes MUST be 443 defined during VPWS setup, MUST be the same in both directions of the 444 VPWS and MUST remain unchanged for the lifetime of the VPWS. 446 For constant bit rate payloads the PLE packet is filled with incoming 447 bits of the bit stream starting from the most significant to the 448 least significant bit. 450 All PLE implementations MUST be capable of supporting the default 451 payload size of 1024 bytes. 453 For PCS based CE interface types supporting FEC the NSP function MUST 454 terminate the FEC and pass the PCS encoded signal to the IWF 455 function. 457 For PCS based CE interface types supporting virtual lanes (i.e. 458 100GE) a PLE payload MUST carry information from all virtual lanes in 459 a bit interleaved manner after the NSP function has performed PCS 460 layer de-skew and re-ordering. 462 A PLE implementation MUST support the transport of all service types 463 except ODUk bit-streams using the constant bit rate payload. 465 5.2. Byte aligned Payload 467 In case of an OTN bit-stream, the NSP function MUST present to the 468 IWF an extended ODUk including a valid frame alignment overhead. The 469 IWF is performing byte-aligned mapping into PLE packets. The egress 470 NSP function will recover the ODUk by searching for the frame 471 alignment overhead. 473 For byte aligned payloads PLE uses the following order for 474 packetization: 476 o The order of the payload bytes corresponds to their order on the 477 attachment circuit. 479 o Consecutive bits coming from the attachment circuit fill each 480 payload byte starting from most significant bit to least 481 significant. 483 All PLE implementations MUST support the payload size of 1024 bytes. 485 All PLE implementations MUST support the transport of OTN bit-streams 486 using the byte aligned payload. 488 6. PLE Operation 490 6.1. Common Considerations 492 A PLE VPWS can be established using manual configuration or 493 leveraging mechanisms of a signalling protocol 495 Furthermore emulation of bit-stream signals using PLE is only 496 possible when the two attachment circuits of the VPWS are of the same 497 type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE payload 498 type and payload size. This can be ensured via manual configuration 499 or via a signalling protocol 501 Extensions to the PWE3 [RFC4447] and EVPN-VPWS [RFC8214] control 502 protocols are described in a separate document [PLESIG]. 504 6.2. PLE IWF Operation 506 6.2.1. PSN-bound Encapsulation Behavior 508 After the VPWS is set up, the PSN-bound IWF does perform the 509 following steps: 511 o Packetise the data received from the CE is into a fixed size PLE 512 payloads 514 o Add PLE control word and RTP header with sequence numbers, flags 515 and timestamps properly set 517 o Add the VPWS demultiplexer and PSN headers 519 o Transmit the resulting packets over the PSN 521 o Set L bit in the PLE control word whenever attachment circuit 522 detects a fault 524 o Set R bit in the PLE control word whenever the local CE-bound IWF 525 is in packet loss state 527 6.2.2. CE-bound Decapsulation Behavior 529 The CE-bound IWF is responsible for removing the PSN and VPWS 530 demultiplexing headers, PLE control word and RTP header from the 531 received packet stream and play-out of the bit-stream to the local 532 attachment circuit. 534 A de-jitter buffer MUST be implemented where the PLE packets are 535 stored upon arrival. The size of this buffer SHOULD be locally 536 configurable to allow accommodation of specific PSN packet delay 537 variation expected. 539 The CE-bound IWF SHOULD use the sequence number in the control word 540 to detect lost and mis-ordered packets. It MAY use the sequence 541 number in the RTP header for the same purposes. 543 The payload of a lost packet MUST be replaced with equivalent amount 544 of replacement data. The contents of the replacement data MAY be 545 locally configurable. All PLE implementations MUST support 546 generation of "0xAA" as replacement data. The alternating sequence 547 of 0s and 1s of the "0xAA" pattern does ensure clock synchronization 548 is maintained. While playing out the replacement data, the IWF will 549 apply a holdover mechanism to maintain the clock. 551 Whenever the VPWS is not operationally up, the CE-bound NSP function 552 MUST inject the appropriate native downstream fault indication signal 553 (for example ODUk-AIS or ethernet LF). 555 Whenever a VPWS comes up, the CE-bound IWF enters the intermediate 556 state, will start receiving PLE packets and will store them in the 557 jitter buffer. The CE-bound NSP function will continue to inject the 558 appropriate native downstream fault indication signal until a pre- 559 configured amount of payloads is stored in the jitter buffer. 561 After the pre-configured amount of payload is present in the jitter 562 buffer the CE-bound IWF transitions to the normal operation state and 563 the content of the jitter buffer is played out to the CE in 564 accordance with the required clock. In this state the CE-bound IWF 565 MUST perform egress clock recovery. 567 The recovered clock MUST comply with the jitter and wander 568 requirements applicable to the type of attachment circuit, specified 569 in: 571 o [G.825] and [G.823] for SDH 573 o [GR253] for SONET 575 o [G.8261] for synchronous ethernet 577 o [G.8251] for OTN 579 Whenever the L bit is set in the PLE control word of a received PLE 580 packet the CE-bound NSP function SHOULD inject the appropriate native 581 downstream fault indication signal instead of playing out the 582 payload. 584 If the CE-bound IWF detects loss of consecutive packets for a pre- 585 configured amount of time (default is 1 millisecond), it enters 586 packet loss (PLOS) state and a corresponding defect is declared. 588 If the CE-bound IWF detects a packet loss ratio (PLR) above a 589 configurable signal-degrade (SD) threshold for a configurable amount 590 of consecutive 1-second intervals, it enters the degradation (DEG) 591 state and a corresponding defect is declared. Possible values for 592 the SD-PLR threshold are between 1..100% with the default being 15%. 594 Possible values for consecutive intervals are 2..10 with the default 595 7. 597 While either a PLOS or DEG defect is declared the CE-bound NSP 598 function SHOULD inject the appropriate native downstream fault 599 indication signal. Also the PSN-bound IWF SHOULD set the R bit in 600 the PLE control word of every packet transmitted. 602 The CE-bound IWF does change from the PLOS to normal state after the 603 pre-configured amount of payload has been received similarly to the 604 transition from intermediate to normal state. 606 Whenever the R bit is set in the PLE control word of a received PLE 607 packet the PLE performance monitoring statistics SHOULD get updated. 609 6.3. PLE Performance Monitoring 611 PLE SHOULD provide the following functions to monitor the network 612 performance to be inline with expectations of transport network 613 operators. 615 The near-end performance monitors defined for PLE are as follows: 617 ES-PLE : PLE Errored Seconds 619 SES-PLE : PLE Severely Errored Seconds 621 UAS-PLE : PLE Unavailable Seconds 623 Each second with at least one packet lost or a PLOS/DEG defect SHALL 624 be counted as ES-PLE. Each second with a PLR greater than 15% or a 625 PLOS/DEG defect SHALL be counted as SES-PLE. 627 UAS-PLE SHALL be counted after configurable number of consecutive 628 SES-PLE have been observed, and no longer counted after a 629 configurable number of consecutive seconds without SES-PLE have been 630 observed. Default value for each is 10 seconds. 632 Once unavailability is detected, ES and SES counts SHALL be inhibited 633 up to the point where the unavailability was started. Once 634 unavailability is removed, ES and SES that occurred along the 635 clearing period SHALL be added to the ES and SES counts. 637 A PLE far-end performance monitor is providing insight into the CE- 638 bound IWF at the far end of the PSN. The statistics are based on the 639 PLE-RDI indication carried in the PLE control word via the R bit. 641 The PLE VPWS performance monitors are derived from the definitions in 642 accordance with [G.826] 644 6.4. QoS and Congestion Control 646 The PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS 647 representing constant bit-rate (CBR) flows cannot respond to 648 congestion in a TCP-friendly manner as described in [RFC2913]. 650 Hence the PSN providing connectivity for the PLE VPWS between PE 651 devices MUST be Diffserv [RFC2475] enabled and MUST provide a per 652 domain behavior [RFC3086] that guarantees low jitter and low loss. 654 To achieve the desired per domain behavior PLE VPWS SHOULD be carried 655 over traffic-engineering paths through the PSN with bandwidth 656 reservation and admission control applied. 658 7. Security Considerations 660 As PLE is leveraging VPWS as transport mechanism the security 661 considerations described in [RFC7432] and [RFC3985] are applicable. 663 8. IANA Considerations 665 Applicable signalling extensions are out of the scope of this 666 document. 668 PLE does not introduce additional requirements from IANA. 670 9. Acknowledgements 672 The authors would like to thank Andreas Burk for reviewing this 673 document and providing useful comments and suggestions. 675 10. References 677 10.1. Normative References 679 [G.823] International Telecommunication Union (ITU), "G.823: The 680 control of jitter and wander within digital networks which 681 are based on the 2048 kbit/s hierarchy", 682 . 684 [G.825] International Telecommunication Union (ITU), "G.825: The 685 control of jitter and wander within digital networks which 686 are based on the synchronous digital hierarchy (SDH)", 687 . 689 [G.8251] International Telecommunication Union (ITU), "G.8251: The 690 control of jitter and wander within the optical transport 691 network (OTN)", . 693 [G.8261] International Telecommunication Union (ITU), "G.8261: 694 Timing and synchronization aspects in packet networks", 695 . 697 [PLESIG] IETF, "Private Line Emulation VPWS Signalling", 698 . 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", BCP 14, RFC 2119, 703 DOI 10.17487/RFC2119, March 1997, 704 . 706 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 707 and W. Weiss, "An Architecture for Differentiated 708 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 709 . 711 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 712 Differentiated Services Per Domain Behaviors and Rules for 713 their Specification", RFC 3086, DOI 10.17487/RFC3086, 714 April 2001, . 716 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 717 Jacobson, "RTP: A Transport Protocol for Real-Time 718 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 719 July 2003, . 721 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 722 Video Conferences with Minimal Control", STD 65, RFC 3551, 723 DOI 10.17487/RFC3551, July 2003, 724 . 726 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 727 Edge-to-Edge (PWE3) Architecture", RFC 3985, 728 DOI 10.17487/RFC3985, March 2005, 729 . 731 [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation 732 of Time Division Multiplexed (TDM) Circuits over Packet 733 Switching Networks", RFC 4197, DOI 10.17487/RFC4197, 734 October 2005, . 736 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 737 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 738 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 739 February 2006, . 741 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 742 G. Heron, "Pseudowire Setup and Maintenance Using the 743 Label Distribution Protocol (LDP)", RFC 4447, 744 DOI 10.17487/RFC4447, April 2006, 745 . 747 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 748 2 Virtual Private Networks (L2VPNs)", RFC 4664, 749 DOI 10.17487/RFC4664, September 2006, 750 . 752 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 753 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 754 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 755 2015, . 757 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 758 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 759 May 2017, . 761 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 762 Rabadan, "Virtual Private Wire Service Support in Ethernet 763 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 764 . 766 10.2. Informative References 768 [G.707] ITU-T, "Network node interface for the synchronous digital 769 hierarchy (SDH)", . 771 [G.709] International Telecommunication Union (ITU), "G.709: 772 Interfaces for the optical transport network", 773 . 775 [G.826] ITU-T, "End-to-end error performance parameters and 776 objectives for international, constant bit-rate digital 777 paths and connections", 778 . 780 [GR253] Telcordia, "SONET Transport Systems : Common Generic 781 Criteria", . 783 [RFC2913] Klyne, G., "MIME Content Types in Media Feature 784 Expressions", RFC 2913, DOI 10.17487/RFC2913, September 785 2000, . 787 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 788 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 789 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 790 . 792 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 793 Agnostic Time Division Multiplexing (TDM) over Packet 794 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 795 . 797 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 798 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 799 October 2007, . 801 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 802 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 803 Circuit Emulation Service over Packet Switched Network 804 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 805 . 807 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 808 Decraene, B., Litkowski, S., and R. Shakir, "Segment 809 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 810 July 2018, . 812 [SRPOLICY] 813 IETF, "Segment Routing Policy Architecture", 814 . 817 [SRV6NETPROG] 818 IETF, "SRv6 Network Programming", 819 . 822 Authors' Addresses 824 Steven Gringeri 825 Verizon 827 Email: steven.gringeri@verizon.com 828 Jeremy Whittaker 829 Verizon 831 Email: jeremy.whittaker@verizon.com 833 Nicolai Leymann 834 Deutsche Telekom 836 Email: N.Leymann@telekom.de 838 Christian Schmutzer (editor) 839 Cisco Systems, Inc. 841 Email: cschmutz@cisco.com 843 Luca Della Chiesa 844 Cisco Systems, Inc. 846 Email: ldellach@cisco.com 848 Nagendra Kumar Nainar (editor) 849 Cisco Systems, Inc. 851 Email: naikumar@cisco.com 853 Carlos Pignataro 854 Cisco Systems, Inc. 856 Email: cpignata@cisco.com 858 Gerald Smallegange 859 Ciena Corporation 861 Email: gsmalleg@ciena.com 863 Chris Brown 864 Ciena Corporation 866 Email: cbrown@ciena.com 867 Faisal Dada 868 Xilinx 870 Email: faisald@xilinx.com