Network Working Group A. Malis
Request for Comments: 4720 Tellabs
Category: Standards Track D. Allan
Nortel Networks
N. Del Regno
MCI
November 2006
Pseudowire Emulation Edge-to-Edge (PWE3)
Frame Check Sequence Retention
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
This document defines a mechanism for preserving Frame Check Sequence
(FCS) through Ethernet, Frame Relay, High-Level Data Link Control
(HDLC), and PPP pseudowires.
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
Malis, et al. Standards Track [Page 1]
RFC 4720 PWE3 Frame Check Sequence Retention November 2006
1. Overview
The specifications for Ethernet, Frame Relay, HDLC, and PPP
pseudowire encapsulation [1] [2] [3] [9] [10] [11] include a mode of
use whereby frames are transparently delivered across the pseudowire
without any header or other alterations by the pseudowire ingress or
egress Provider Edge (PE). (Note that this mode is inherent for HDLC
and PPP Pseudowires.)
However, these specifications all specify that the original Frame
Check Sequence (FCS) be removed at ingress and regenerated at egress,
which means that the frames may be subject to unintentional
alteration during their traversal of the pseudowire from the ingress
to the egress PE. Thus, the pseudowire cannot absolutely be
guaranteed to be "transparent" in nature.
To be more precise, pseudowires, as currently defined, leave the
payload vulnerable to unintended modification occurring while
transiting the encapsulating network. Not only can a PW-aware device
internally corrupt an encapsulated payload, but ANY LSR or router in
the path can corrupt the encapsulated payload. In the event of such
corruption, there is no way to detect the corruption through the path
of the pseudowire. Further, because the FCS is calculated upon
network egress, any corruption will pass transparently through ALL
Layer 2 switches (Ethernet and Frame Relay) through which the packets
travel. Only at the endpoint, assuming that the corrupted packet
even reaches the correct endpoint, can the packet be discarded, and
depending on the contents of the packet, the corruption may not ever
be detected.
Not only does the encapsulation technique leave the payload
unprotected, it also subverts the error checking mechanisms already
in place in SP and customer networks by calculating FCS on
questionable data.
In a perfect network comprising perfect equipment, this is not an
issue. However, as there is no such thing, it is an issue. SPs
should have the option of saving overhead by yielding the ability to
detect faults. Equally, SPs should have the option to sacrifice the
overhead of carrying the original FCS end-to-end to ensure the
ability to detect faults in the encapsulating network.
This document defines such a mechanism to allow the ingress PE to
retain the original frame FCS on ingress to the network, and it
relieves the egress PE of the task of regenerating the FCS.
Malis, et al. Standards Track [Page 2]
RFC 4720 PWE3 Frame Check Sequence Retention November 2006
This is an OPTIONAL mechanism for pseudowire implementations. For
interoperability with systems that do not implement this document,
datatracker.ietf.org