RFC 4720

Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention

📅 published November 2006, from ietf

RFC 4720: Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention 🎀

  • RFC: 4720
  • Stream: Network Working Group
  • Title: Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
  • Authors: A. Malis (Tellabs), D. Allan (Nortel Networks), N. Del Regno (MCI)
  • Category: Standards Track
  • Date: November 2006
  • Obsoletes / Updates: none listed in this title block

Status of This Memo 📜

okay so this one is an Internet standards track protocol for the Internet community 🫶 It's asking for discussion and suggestions for improvements, so bring your ideas. If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with your whole group chat 💌

Copyright (C) The IETF Trust (2006).

Abstract ✨

this doc defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires. so the FCS survives the whole trip 🦋

Table of Contents 🗂️

1. Overview ........................................................1
2. Specification of Requirements ...................................3
3. Signaling FCS Retention with MPLS-Based Pseudowires .............3
4. Signaling FCS Retention with L2TPv3-Based Pseudowires ...........4
5. Security Considerations .........................................5
6. Applicability Statement .........................................5
7. IANA Considerations .............................................6
8. Acknowledgement .................................................6
9. Normative References ............................................6

1. Overview 🌸

okay so the specs for Ethernet, Frame Relay, HDLC, and PPP pseudowire encapsulation [1] [2] [3] [9] [10] [11] have a mode where frames get delivered transparently across the pseudowire, with no header or other changes made by the ingress or egress Provider Edge (PE). (Fun fact: this mode is inherent for HDLC and PPP Pseudowires 🧚)

BUT. 😭 those same specs say the original Frame Check Sequence (FCS) gets removed at ingress and regenerated at egress. That means frames can get accidentally altered while they travel the pseudowire from the ingress PE to the egress PE. So the pseudowire can't absolutely be guaranteed to be "transparent" 💀

to be more precise, pseudowires as they're currently defined leave the payload open to unintended changes while it's crossing the encapsulating network. A PW-aware device can corrupt an encapsulated payload internally, and ANY LSR or router on the path can corrupt it too. If that happens, there's no way to detect the corruption along the pseudowire path. Also, since the FCS gets calculated at network egress, any corruption passes right through ALL Layer 2 switches (Ethernet and Frame Relay) the packets travel through. The packet only gets discarded at the endpoint, and only if it even reaches the right endpoint. And depending on what's in the packet, the corruption might never be detected at all 😱

it's not just that the payload is unprotected. The encapsulation technique also undermines the error checking mechanisms already in place in SP and customer networks, because it calculates the FCS on questionable data 🙈

in a perfect network with perfect equipment this wouldn't be an issue. But there's no such thing, so it IS an issue 💅 SPs should be able to choose between saving overhead by giving up the ability to detect faults, and sacrificing the overhead of carrying the original FCS end-to-end so they can still detect faults in the encapsulating network. Both options should be on the table ✨

this document defines a mechanism that lets the ingress PE retain the original frame FCS on ingress to the network. It also takes the job of regenerating the FCS off the egress PE 🎀

this is an OPTIONAL mechanism for pseudowire implementations. For interoperability with systems that don't implement this document, the default behavior is that the FCS is removed at the ingress PE and regenerated at the egress PE, as specified in [1], [2], and [3].

this capability may be used ONLY with Ethernet pseudowires that use "raw mode" [1], Frame Relay pseudowires that use "port mode" [2] [3], and HDLC and PPP pseudowires [3].

⚠️ this mechanism is NOT meant to carry errored frames through the pseudowire. As usual, the FCS MUST be examined at the ingress PE, and errored frames MUST be discarded. The FCS MAY also be examined by the egress PE. If it is, errored frames MUST be discarded there too. The egress PE MAY also want to generate an alarm or count the number of errored frames 🚨

2. Specification of Requirements 📋

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. Those are the official requirement words, so read them carefully 🤓

3. Signaling FCS Retention with MPLS-Based Pseudowires 🦋

when you use the signaling procedures in [4], there's a Pseudowire Interface Parameter Sub-TLV type that signals the desire to retain the FCS when advertising a VC label [5]:

   Parameter      Length    Description
        0x0A           4    FCS Retention Indicator

the presence of this parameter means the egress PE is asking the ingress PE to retain the FCS for the VC label being advertised. It does NOT obligate the ingress PE to retain the FCS. It's just an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter is not present in the VC FEC element. So no parameter, no retention 🙅‍♀️

the parameter includes a 16-bit FCS length field, which tells you the length of the original FCS being retained. For Ethernet pseudowires, this length will ALWAYS be set to 4. For HDLC, PPP, and Frame Relay pseudowires, it will be set to either 2 or 4. The FCS length on these interfaces is a local setting, so retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Putting the FCS length in this parameter lets the PEs make sure the FCS is only retained when it makes sense 💖

unknown parameters are silently ignored [4], so backward compatibility with systems that don't implement this document is handled by requiring that the FCS be retained ONLY if the FCS Retention Indicator with an identical setting for the FCS length has been included in the advertisements for BOTH directions on a pseudowire. Both sides have to agree, bestie 🫶

if the ingress PE recognizes the FCS Retention Indicator parameter but does NOT want to retain the FCS with the indicated length, it only needs to issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. That stops FCS retention in either direction 🛑

if PWE3 signaling [4] is not in use for a pseudowire, then whether the FCS is to be retained MUST be provisioned identically in both PEs at the pseudowire endpoints. If there's no provisioning support for this option, the default behavior is to remove the FCS 📝

4. Signaling FCS Retention with L2TPv3-Based Pseudowires 🧚

this section uses the following terms as defined in [7]:

  • Incoming-Call-Request (ICRQ)
  • Incoming-Call-Reply (ICRP)
  • Incoming-Call-Connected (ICCN)
  • Attribute Value Pair (AVP)
  • L2TP Control Connection Endpoint (LCCE)

when you use the signaling procedures in [7], the FCS Retention AVP, Attribute Type 92, is used. 🎀

the Attribute Value field for this AVP has the following format:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          FCS Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the FCS Length is a 2-octet unsigned integer 🔢

the presence of this AVP in an ICRQ or ICRP message means an LCCE (PE) is requesting that its peer retain FCS for the L2TP session being established. If the receiving LCCE recognizes the AVP and complies with the FCS retention request, it MUST include an FCS Retention AVP as an acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is ALWAYS bidirectional. So FCS is only retained if BOTH LCCEs send an FCS Retention AVP during session establishment 🤝

the Attribute Value is a 16-bit FCS length field, which tells you the length of the original FCS being retained. For Ethernet pseudowires, this length will ALWAYS be set to 4. For HDLC, PPP, and Frame Relay pseudowires, it will be set to either 2 or 4. The FCS length on these interfaces is a local setting, so retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this AVP lets the PEs make sure the FCS is only retained when doing so makes sense 💅

the Length of this AVP is 8. The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0). 🙈

5. Security Considerations 🔐

this mechanism boosts the data integrity of transparent Ethernet, Frame Relay, and HDLC pseudowires. Why? Because the original FCS, as generated by the Customer Edge (CE), is included in the encapsulation. When the encapsulated payload passes FCS checking at the destination CE, you know the payload wasn't altered during its transmission through the network. Or at least, you know it's accurate to the original FCS. But that's demonstrably better than having no FCS at all 😤

of course, nothing comes for free 💀 this requires the extra overhead of carrying the original FCS, which is generally either two or four octets per payload packet.

this signaling is backward compatible and interoperable with systems that do not implement this document 🫶

6. Applicability Statement ✨

Okay so this doc is basically here to extend the applicability of the services from [1], [2], and [3] 💖 It makes them way more suitable for deployments where data integrity is a big deal (or at least as big a deal as it was in the original services that defined FCS usage in the first place). 🫶 Not every situation needs this, though. If the inner payloads already have their own error-checking, like TCP does, you don't need the extra layer. 💅 But for inner payloads that rely on the link layer's error detection, like SNA, this extra protection is literally invaluable 😭

When pseudowires connect 802.1 bridges, this document lets them meet the rule that all media interconnecting 802.1 bridges have (at least) 32-bit FCS protection. 🌸 Main character energy for pseudowires, ngl 👑

Also, this document is just one option a service provider can use to boost end-to-end data integrity on pseudowires 🦋 Other options include end-to-end IPsec between the PEs, or internal mechanisms in the P routers that keep packets intact while they're switched between ingress and egress interfaces. 🧚 SPs should compare how strong each approach is when they plan their pseudowire deployments 🍓 That said, it can be kinda wasteful for an SP to use an end-to-end integrity mechanism that is STRONGER than the FCS generated by the source CE and checked by the destination CE 💀

7. IANA Considerations 🎀

This document doesn't specify any new registries for IANA to maintain. 🌈

Heads up: [5] already allocates the FCS Retention Indicator interface parameter, so no further IANA action is needed ✨

IANA assigned one value in the L2TP "Control Message Attribute Value Pairs" section, as per [8] 💜 The new AVP is 92, and the IANA L2TP parameters registry calls it "FCS Retention" 🔥

8. Acknowledgement 🫶

The authors want to thank Mark Townsley for the text in Section 4 💖

9. Normative References 📚

  • [1] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
  • [2] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
  • [3] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
  • [4] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
  • [5] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
  • [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [7] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
  • [8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
  • [9] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4719, November 2006.
  • [10] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4591, August 2006.
  • [11] Pignataro, C. and M. Townsley, "High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)", RFC 4349, February 2006.

Authors' Addresses 💌

Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134

EMail: Andy.Malis@tellabs.com

David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA

EMail: dallan@nortel.com

Nick Del Regno MCI 400 International Parkway Richardson, TX 75081

EMail: nick.delregno@mci.com

Copyright (C) The IETF Trust (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔐

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🦋

📦 where this page comes from