datatracker.ietf.org
Sign in
Version 5.6.1.p1, 2014-07-16
Report a bug

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

Document type: RFC - Proposed Standard (November 2006)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4720 (Proposed Standard)
Responsible AD: Mark Townsley
Send notices to: stbryant@cisco.com, danny@arbor.net

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,

[include full document text]