idnits 2.17.1 draft-schmutzer-bess-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2020) is 1378 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. '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 (==), 2 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: January 13, 2021 C. Schmutzer, Ed. 6 L. Della Chiesa 7 N. Nainar, Ed. 8 C. Pignataro 9 Cisco Systems, Inc. 10 July 12, 2020 12 Private Line Emulation over Packet Switched Networks 13 draft-schmutzer-bess-ple-00 15 Abstract 17 This document describes a method for encapsulating high-speed bit- 18 streams as virtual private wire services (VPWS) over packet switched 19 networks (PSN) providing complete signal transport transparency. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 13, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Motivations . . . . . . . . . . . . . . . . 2 56 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 57 3. Terminology and Reference Model . . . . . . . . . . . . . . . 3 58 3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Reference Models . . . . . . . . . . . . . . . . . . . . 4 60 4. PLE Encapsulation Layer . . . . . . . . . . . . . . . . . . . 6 61 4.1. PSN and VPWS Demultiplexing Headers . . . . . . . . . . . 7 62 4.2. PLE Header . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2.1. PLE Control Word . . . . . . . . . . . . . . . . . . 7 64 4.2.2. RTP Header . . . . . . . . . . . . . . . . . . . . . 8 65 5. PLE Payload Layer . . . . . . . . . . . . . . . . . . . . . . 10 66 5.1. Constant Bit Rate Payload . . . . . . . . . . . . . . . . 10 67 5.2. ODUk Frame aligned Payload . . . . . . . . . . . . . . . 10 68 6. PLE Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Common Considerations . . . . . . . . . . . . . . . . . . 11 70 6.2. PLE IWF Operation . . . . . . . . . . . . . . . . . . . . 11 71 6.2.1. PSN-bound Encapsulation Behavior . . . . . . . . . . 11 72 6.2.2. CE-bound Decapsulation Behavior . . . . . . . . . . . 12 73 6.3. PLE Performance Monitoring . . . . . . . . . . . . . . . 13 74 6.4. QoS and Congestion Control . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 10.2. Informative References . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction and Motivations 85 This document describes a method for encapsulating high-speed bit- 86 streams as VPWS over packet switched networks (PSN). This emulation 87 suits applications where complete signal transparency is required and 88 data interpretation of the PE would be counter productive. 90 One example is two ethernet connected CEs and the need for 91 synchronous ethernet operation between then without the intermediate 92 PEs interfering. Another example is addressing common ethernet 93 control protocol transparency concerns for carrier ethernet services, 94 beyond the behavior definitions of MEF specifications. 96 The mechanisms described in this document allow the transport of 97 signals from many technologies such as ethernet, fibre channel, 98 SONET/SDH [GR253]/[G.707] and OTN [G.709] by treating them as bit- 99 stream payload defined in Section 3.3.3 of [RFC3985]. 101 2. Requirements Notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in BCP 106 14 [RFC2119] [RFC8174] when, and only when, they appear in all 107 capitals, as shown here. 109 3. Terminology and Reference Model 111 3.1. Terminology 113 o ACH - Associated Channel Header 115 o AIS - Alarm Indication Signal 117 o CBR - Constant Bit Rate 119 o CE - Customer Edge 121 o CSRC - Contributing SouRCe 123 o ES - Errored Second 125 o FEC - Forward Error Correction 127 o IWF - InterWorking Function 129 o LDP - Label Distribution Protocol 131 o LF - Local Fault 133 o MPLS - Multi Protocol Label Switching 135 o NSP - Native Service Processor 137 o ODUk - Optical Data Unit k 139 o OTN - Optical Transport Network 141 o OTUk - Optical Transport Unit k 143 o PCS - Physical Coding Sublayer 144 o PE - Provider Edge 146 o PLE - Private Line Emulation 148 o PLOS - Packet Loss Of Signal 150 o PSN - Packet Switched Network 152 o P2P - Point-to-Point 154 o QOS - Quality Of Service 156 o RSVP-TE - Resource Reservation Protocol Traffic Engineering 158 o RTCP - RTP Control Protocol 160 o RTP - Realtime Transport Protocol 162 o SES - Severely Errored Seconds 164 o SDH - Synchronous Digital Hierarchy 166 o SRTP - Secure Realtime Transport Protocol 168 o SRv6 - Segment Routing over IPv6 Dataplane 170 o SSRC - Synchronization SouRCe 172 o SONET - Synchronous Optical Network 174 o TCP - Transmission Control Protocol 176 o UAS - Unavailable Seconds 178 o VPWS - Virtual Private Wire Service 180 Similarly to [RFC4553] and [RFC5086] the term Interworking Function 181 (IWF) is used to describe the functional block that encapsulates bit 182 streams into PLE packets and in the reverse direction decapsulates 183 PLE packets and reconstructs bit streams. 185 3.2. Reference Models 187 The generic models defined in [RFC4664] are applicable to PLE. 189 PLE embraces the minimum intervention principle outlined in section 190 3.3.5 of [RFC3985] whereas the data is flowing through the PLE 191 encapsulation layer as received without modifications. 193 For some applications the NSP function is responsible for performing 194 operations on the native data received from the CE. Examples are 195 terminating FEC in case of 100GE or terminating the OTUk layer for 196 OTN. After the NSP the IWF is generating the payload of the VPWS 197 which carried via a PSN tunnel. 199 |<--- p2p L2VPN service -->| 200 | | 201 | |<-PSN tunnel->| | 202 v v v v 203 +---------+ +---------+ 204 | PE1 |==============| PE2 | 205 +---+-----+ +-----+---+ 206 +-----+ | N | | | | N | +-----+ 207 | CE1 |-----| S | IWF |.....VPWS.....| IWF | S |-----| CE2 | 208 +-----+ ^ | P | | | | P | ^ +-----+ 209 | +---+-----+ +-----+---+ | 210 CE1 physical ^ ^ CE2 physical 211 interface | | interface 212 |<--- emulated service --->| 213 | | 214 attachment attachment 215 circuit circuit 217 Figure 1: PLE Reference Model 219 To allow the clock of the transported signal to be carried across the 220 PLE domain in a transparent way the network synchronization reference 221 model and deployment scenario outlined in section 4.3.2 of [RFC4197] 222 is applicable. 224 J 225 | G 226 v | 227 +-----+ +-----+ v 228 +-----+ |- - -|=================|- - -| +-----+ 229 | |<---------|.............................|<---------| | 230 | CE1 | | PE1 | VPWS | PE2 | | CE2 | 231 | |--------->|.............................|--------->| | 232 +-----+ |- - -|=================|- - -| +-----+ 233 ^ +-----+<-------+------->+-----+ 234 | | ^ 235 A +-+ | 236 |I| E 237 +-+ 239 Figure 2: Relative Network Scenario Timing 241 The attachment circuit clock E is generated by PE2 in reference to a 242 common clock I. For this to work the difference between clock I and 243 A MUST be explicitly transferred between the PE1 and PE2 using the 244 timestamp inside the RTP header. 246 For the reverse direction PE1 does generate the clock J in reference 247 to clock I and the clock difference between I and G. 249 4. PLE Encapsulation Layer 251 The basic packet format used by PLE is shown in the below figure. 253 +-------------------------------+ -+ 254 | PSN and VPWS Demux | \ 255 | (MPLS/SRv6) | > PSN and VPWS 256 | | / Demux Headers 257 +-------------------------------+ -+ 258 | PLE Control Word | \ 259 +-------------------------------+ > PLE Header 260 | RTP Header | / 261 +-------------------------------+ --+ 262 | Bit Stream | \ 263 | Payload | > Payload 264 | | / 265 +-------------------------------+ --+ 267 Figure 3: PLE Encapsulation Layer 269 4.1. PSN and VPWS Demultiplexing Headers 271 This document does not imply any specific technology to be used for 272 implementing the VPWS demultiplexing and PSN layers. 274 When a MPLS PSN layer is used. A VPWS label provides the 275 demultiplexing mechanism as described in section 5.4.2 of [RFC3985]. 276 The PSN tunnel can be a simple best path Label Switched Path (LSP) 277 established using LDP [RFC5036] or Segment Routing [RFC8402] or a 278 traffic engineered LSP established using RSVP-TE [RFC3209] or SR-TE 279 [SRPOLICY]. 281 When PLE is applied to a SRv6 based PSN, the mechanisms defined in 282 [RFC8402] and the End.DX2 endpoint behavior defined in [SRV6NETPROG] 283 do apply. 285 4.2. PLE Header 287 The PLE header MUST contain the PLE control word (4 bytes) and MUST 288 include a fixed size RTP header [RFC3550]. The RTP header MUST 289 immediately follow the PLE control word. 291 4.2.1. PLE Control Word 293 The format of the PLE control word is inline with the guidance in 294 [RFC4385] and as shown in the below figure: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 4: PLE Control Word 304 The first nibble is used to differentiate if it is a control word or 305 Associated Channel Header (ACH). The first nibble MUST be set to 306 0000b to indicate that this header is a control word as defined in 307 section 3 of [RFC4385]. 309 The other fields in the control word are used as defined below: 311 L 313 Set by the PE to indicate that data carried in the payload is 314 invalid due to an attachment circuit fault (client signal 315 failure). The downstream PE MUST play out an appropriate 316 replacement data. The NSP MAY inject an appropriate native fault 317 propagation signal. 319 R 321 Set by the downstream PE to indicate that the IWF experiences 322 packet loss from the PSN or a server layer backward fault 323 indication is present in the NSP. The R bit MUST be cleared by 324 the PE once the packet loss state or fault indication has cleared. 326 RSV 328 These bits are reserved for future use. This field MUST be set to 329 zero by the sender and ignored by the receiver. 331 FRG 333 These bits MUST be set to zero by the sender and ignored by the 334 receiver except for frame aligned payloads; see Section 5.2 336 LEN 338 In accordance to [RFC4385] section 3 the length field MUST always 339 be set to zero as there is no padding added to the PLE packet. To 340 detect malformed packets the default, preconfigured or signaled 341 payload size MUST be assumed. 343 Sequence Number 345 The sequence number field is used to provide a common PW 346 sequencing function as well as detection of lost packets. It MUST 347 be generated in accordance with the rules defined in Section 5.1 348 of [RFC3550] for the RTP sequence number and MUST be incremented 349 with every PLE packet being sent. 351 4.2.2. RTP Header 353 The RTP header MUST be included and is used for explicit transfer of 354 timing information. The RTP header is purely a formal reuse and RTP 355 mechanisms, such as header extensions, contributing source (CSRC) 356 list, padding, RTP Control Protocol (RTCP), RTP header compression, 357 Secure Realtime Transport Protocol (SRTP), etc., are not applicable 358 to PLE VPWS. 360 The format of the RTP header is as shown in the below figure: 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |V=2|P|X| CC |M| PT | Sequence Number | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Timestamp | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Synchronization Source (SSRC) Identifier | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 5: RTP Header 374 V: Version 376 The version field MUST be set to 2. 378 P: Padding 380 The padding flag MUST be set to zero by the sender and ignored by 381 the receiver. 383 X: Header Extension 385 The X bit MUST be set to zero by sender and ignored by receiver. 387 CC: CSRC Count 389 The CC field MUST be set to zero by the sender and ignored by the 390 receiver. 392 M: Marker 394 The M bit MUST be set to zero by sender and ignored by receiver. 396 PT: Payload Type 398 A PT value MUST be allocated from the range of dynamic values 399 define by [RFC3551] for each direction of the VPWS. The same PT 400 value MAY be reused both for direction and between different PLE 401 VPWS. 403 Sequence Number 405 The packet sequence number MUST continuously cycle from 0 to 406 0xFFFF. It is generated and processed in accordance with the 407 rules established in [RFC3550]. The PLE receiver MUST sequence 408 packets according to the Sequence Number field of the PLE control 409 word and MAY verify correct sequencing using RTP Sequence Number 410 field. 412 Timestamp 414 Timestamp values are used in accordance with the rules established 415 in [RFC3550]. Frequency of the clock used for generating 416 timestamps MUST be 25 MHz based on a local reference. 418 SSRC: Synchronization Source 420 The SSRC field MAY be used for detection of misconnections. 422 5. PLE Payload Layer 424 5.1. Constant Bit Rate Payload 426 A bit-stream is mapped into a packet with a fixed payload size 427 ignoring any structure being present. The number of bytes MUST be 428 defined during VPWS setup, MUST be the same in both directions of the 429 VPWS and MUST remain unchanged for the lifetime of the VPWS. 431 All PLE implementations MUST be capable of supporting the default 432 payload size of 480 bytes. 434 For PCS based CE interface types supporting FEC the NSP function MUST 435 terminate the FEC and pass the PCS encoded signal to the IWF 436 function. 438 For PCS based CE interface types supporting virtual lanes (i.e. 439 100GE) a PLE payload MUST carry information from all virtual lanes in 440 a bit interleaved manner after the NSP function has performed PCS 441 layer de-skew and re-ordering. 443 A PLE implementation MUST support the transport of all service types 444 except ODUk bit-streams using the constant bit rate payload. 446 5.2. ODUk Frame aligned Payload 448 In case of OTN PLE does only transport the ODUk layer to be bandwidth 449 efficient. This means the OTUk layer which does include the FEC is 450 terminated by NSP function. As OTN is performing frame alignment at 451 the OTUk layer the bit-stream must be carried frame aligned. 453 A ODUk frame consists of 3824 columns and 4 rows which results in a 454 frame size of 15296 bytes. As common PSN MTU sizes are in the range 455 of at most 9200 bytes the ODUk frame has to be fragmented during PLE 456 payload encapsulation. The used payload size has to be a integer 457 fraction of the full 15296 bytes to allow for ODUk frame alignment. 458 All PLE implementations MUST support the payload size of 478 bytes. 460 The two FRG bits in the PLE control word MUST be used to indicate 461 first, intermediate, and last fragment of the encapsulated ODUk frame 462 as described in section 4.1 of [RFC4623]. 464 All PLE implementations MUST support the transport ODUk bit-streams 465 using the frame aligned payload. 467 6. PLE Operation 469 6.1. Common Considerations 471 A PLE VPWS can be established using manual configuration or 472 leveraging mechanisms of a signalling protocol 474 Furthermore emulation of bit-stream signals using PLE is only 475 possible when the two attachment circuits of the VPWS are of the same 476 type (OC192, 10GBASE-R, ODU2, etc) and are using the same PLE payload 477 type and payload size. This can be ensured via manual configuration 478 or via a signalling protocol 480 Extensions to the PWE3 [RFC4447] and EVPN-VPWS [RFC8214] control 481 protocols are described in a separate document [PLESIG]. 483 6.2. PLE IWF Operation 485 6.2.1. PSN-bound Encapsulation Behavior 487 After the VPWS is set up, the PSN-bound IWF does perform the 488 following steps: 490 o Packetise the data received from the CE is into a fixed size PLE 491 payloads 493 o Add PLE control word and RTP header with sequence numbers, flags 494 and timestamps properly set 496 o Add the VPWS demultiplexer and PSN headers 498 o Transmit the resulting packets over the PSN 500 o Set L bit in the PLE control word whenever attachment circuit 501 detects a fault 503 o Set R bit in the PLE control word whenever the local CE-bound IWF 504 is in packet loss state 506 6.2.2. CE-bound Decapsulation Behavior 508 The CE-bound IWF is responsible for removing the PSN and VPWS 509 demultiplexing headers, PLE control word and RTP header from the 510 received packet stream and play-out of the bit-stream to the local 511 attachment circuit. 513 A de-jitter buffer MUST be implemented where the PLE packets are 514 stored upon arrival. The size of this buffer SHOULD be locally 515 configurable to allow accommodation of specific PSN packet delay 516 variation expected. 518 The CE-bound IWF SHOULD use the sequence number in the control word 519 to detect lost packets. It MAY use the sequence number in the RTP 520 header for the same purposes. 522 The payload of a lost packet MUST be replaced with equivalent amount 523 of replacement data. The contents of the replacement data MAY be 524 locally configurable. All PLE implementations MUST support 525 generation of "0xAA" as replacement data. The alternating sequence 526 of 0s and 1s of the "0xAA" pattern does ensure clock synchronization 527 is maintained. 529 Whenever the VPWS is not operationally up, the CE-bound NSP function 530 MUST inject the appropriate native downstream fault indication signal 531 (for example ODUk-AIS or ethernet LF). 533 Whenever a VPWS comes up, the CE-bound IWF will start receiving PLE 534 packets and will store them in the jitter buffer. The CE-bound NSP 535 function will continue to inject the appropriate native downstream 536 fault indication signal until a pre-configured amount of payloads is 537 stored in the jitter buffer. 539 After the pre-configured amount of payload is present in the jitter 540 buffer the CE-bound IWF transitions to the normal operation state and 541 the content of the jitter buffer is played out to the CE in 542 accordance with the required clock. In this state the CE-bound IWF 543 does perform egress clock recovery. 545 Whenever the L bit is set in the PLE control word of a received PLE 546 packet the CE-bound NSP function SHOULD inject the appropriate native 547 downstream fault indication signal instead of playing out the 548 payload. 550 If the CE-bound IWF detects loss of a pre-configured number of 551 consecutive packets, the de-jitter buffer under- or over-runs, it 552 enters packet loss (PLOS) state . While in this state CE-bound NSP 553 function SHOULD inject the appropriate native downstream fault 554 indication signal. Also the PSN-bound IWF SHOULD set the R bit in 555 the PLE control word of every packet transmitted. 557 The CE-bound IWF exits the packet loss state after a pre-configured 558 amount of valid PLE packets have been received. 560 Whenever the R bit is set in the PLE control word of a received PLE 561 packet the PLE performance monitoring statistics SHOULD get updated. 563 6.3. PLE Performance Monitoring 565 PLE SHOULD provide the following functions to monitor the network 566 performance to be inline with expectations of transport network 567 operators. 569 The near-end performance monitors defined for PLE are as follows: 571 ES-PLE : PLE Errored Seconds 573 SES-PLE : PLE Severely Errored Seconds 575 UAS-PLE : PLE Unavailable Seconds 577 Each second that contains at least one lost packet defect SHALL be 578 counted as ES-PLE. Each second that contains a PLOS defect SHALL be 579 counted as SES-PLE. 581 UAS-PLE SHALL be counted after configurable number of consecutive 582 SES-PLE have been observed, and no longer counted after a 583 configurable number of consecutive seconds without SES-PLE have been 584 observed. Default value for each is 10 seconds. 586 Once unavailability is detected, ES and SES counts SHALL be inhibited 587 up to the point where the unavailability was started. Once 588 unavailability is removed, ES and SES that occurred along the 589 clearing period SHALL be added to the ES and SES counts. 591 A PLE far-end performance monitor is providing insight into the CE- 592 bound IWF at the far end of the PSN. The statistics are based on the 593 PLE-RDI indication carried in the PLE control word via the R bit. 595 The PLE VPWS performance monitors are derived from the definitions in 596 accordance with [G.826] 598 6.4. QoS and Congestion Control 600 The PSN carrying PLE VPWS may be subject to congestion, but PLE VPWS 601 representing constant bit-rate (CBR) flows cannot respond to 602 congestion in a TCP-friendly manner as described in [RFC2913]. 604 Hence the PSN providing connectivity for the PLE VPWS between PE 605 devices MUST be Diffserv [RFC2475] enabled and MUST provide a per 606 domain behavior [RFC3086] that guarantees low jitter and low loss. 608 To achieve the desired per domain behavior PLE VPWS SHOULD be carried 609 over traffic-engineering paths through the PSN with bandwidth 610 reservation and admission control applied. 612 7. Security Considerations 614 As PLE is leveraging VPWS as transport mechanism the security 615 considerations described in [RFC7432] and [RFC3985] are applicable. 617 8. IANA Considerations 619 Applicable signalling extensions are out of the scope of this 620 document. 622 PLE does not introduce additional requirements from IANA. 624 9. Acknowledgements 626 To be updated. 628 10. References 630 10.1. Normative References 632 [PLESIG] IETF, "Private Line Emulation VPWS Signalling", 633 . 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", BCP 14, RFC 2119, 638 DOI 10.17487/RFC2119, March 1997, 639 . 641 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 642 and W. Weiss, "An Architecture for Differentiated 643 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 644 . 646 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 647 Differentiated Services Per Domain Behaviors and Rules for 648 their Specification", RFC 3086, DOI 10.17487/RFC3086, 649 April 2001, . 651 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 652 Jacobson, "RTP: A Transport Protocol for Real-Time 653 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 654 July 2003, . 656 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 657 Video Conferences with Minimal Control", STD 65, RFC 3551, 658 DOI 10.17487/RFC3551, July 2003, 659 . 661 [RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation 662 Edge-to-Edge (PWE3) Architecture", RFC 3985, 663 DOI 10.17487/RFC3985, March 2005, 664 . 666 [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation 667 of Time Division Multiplexed (TDM) Circuits over Packet 668 Switching Networks", RFC 4197, DOI 10.17487/RFC4197, 669 October 2005, . 671 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 672 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 673 Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, 674 February 2006, . 676 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 677 G. Heron, "Pseudowire Setup and Maintenance Using the 678 Label Distribution Protocol (LDP)", RFC 4447, 679 DOI 10.17487/RFC4447, April 2006, 680 . 682 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 683 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 684 DOI 10.17487/RFC4623, August 2006, 685 . 687 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 688 2 Virtual Private Networks (L2VPNs)", RFC 4664, 689 DOI 10.17487/RFC4664, September 2006, 690 . 692 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 693 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 694 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 695 2015, . 697 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 698 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 699 May 2017, . 701 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 702 Rabadan, "Virtual Private Wire Service Support in Ethernet 703 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 704 . 706 10.2. Informative References 708 [G.707] ITU-T, "Network node interface for the synchronous digital 709 hierarchy (SDH)", . 711 [G.709] International Telecommunication Union (ITU), "G.709: 712 Interfaces for the optical transport network", 713 . 715 [G.826] ITU-T, "End-to-end error performance parameters and 716 objectives for international, constant bit-rate digital 717 paths and connections", 718 . 720 [GR253] Telcordia, "SONET Transport Systems : Common Generic 721 Criteria", . 723 [RFC2913] Klyne, G., "MIME Content Types in Media Feature 724 Expressions", RFC 2913, DOI 10.17487/RFC2913, September 725 2000, . 727 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 728 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 729 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 730 . 732 [RFC4553] Vainshtein, A., Ed. and YJ. Stein, Ed., "Structure- 733 Agnostic Time Division Multiplexing (TDM) over Packet 734 (SAToP)", RFC 4553, DOI 10.17487/RFC4553, June 2006, 735 . 737 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 738 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 739 October 2007, . 741 [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and 742 P. Pate, "Structure-Aware Time Division Multiplexed (TDM) 743 Circuit Emulation Service over Packet Switched Network 744 (CESoPSN)", RFC 5086, DOI 10.17487/RFC5086, December 2007, 745 . 747 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 748 Decraene, B., Litkowski, S., and R. Shakir, "Segment 749 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 750 July 2018, . 752 [SRPOLICY] 753 IETF, "Segment Routing Policy Architecture", 754 . 757 [SRV6NETPROG] 758 IETF, "SRv6 Network Programming", 759 . 762 Authors' Addresses 764 Steven Gringeri 765 Verizon 767 Email: steven.gringeri@verizon.com 769 Jeremy Whittaker 770 Verizon 772 Email: jeremy.whittaker@verizon.com 774 Christian Schmutzer (editor) 775 Cisco Systems, Inc. 777 Email: cschmutz@cisco.com 779 Luca Della Chiesa 780 Cisco Systems, Inc. 782 Email: ldellach@cisco.com 783 Nagendra Kumar Nainar (editor) 784 Cisco Systems, Inc. 786 Email: naikumar@cisco.com 788 Carlos Pignataro 789 Cisco Systems, Inc. 791 Email: cpignata@cisco.com