Internet Draft Andrew G. Malis
Document: draft-ietf-pwe3-fcs-retention-01.txt Tellabs
Expires: November 2004 David Allan
Nortel Networks
Nick Del Regno
MCI
May 2004
PWE3 Frame Check Sequence Retention
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines a mechanism for preserving frame FCS through
Ethernet, Frame Relay, and HDLC pseudowires.
Table of Contents
1. Specification of Requirements.................................2
2. Overview......................................................2
3. FCS Retention With MPLS-based Pseudowires.....................3
4. FCS Retention With L2TPv3-based Pseudowires...................4
5. Security Considerations.......................................4
6. IANA Considerations...........................................4
7. References....................................................5
8. Authors' Addresses............................................5
Malis et al Expires November 2004 [Page 1]
PWE3 FCS Retention May 2004
1. 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].
2. Overview
The specifications for Ethernet, Frame Relay, HDLC, and PPP
pseudowire encapsulation [1] [2] [3] include a mode of use where
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 be
absolutely guaranteed to be "transparent" in nature.
To be more precise, pseudowires, as currently defined, leave the
payload vulnerable to undetected errors caused by the encapsulating
network. As defined for MPLS, not only can a PW-aware device
internally corrupt an encapsulated payload, but ANY MPLS LSR 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 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.
Malis et al Expires November 2004 [Page 2]
PWE3 FCS Retention May 2004
This document defines such a mechanism to allow the ingress PE to
retain the original frame FCS on ingress to the network, and
relieves the egress PE of the task of regenerating the FCS.
This in an OPTIONAL mechanism for pseudowire implementations. For
interoperability with systems that do not 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].
Note that this mechanism is not intended 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 this is done, errored frames MUST
be discarded. The egress PE MAY also wish to generate an alarm or
count the number of errored frames.
3. Signaling FCS Retention With MPLS-based Pseudowires
When using the signaling procedures in [4], there is a Virtual
Circuit FEC element parameter ID used to signal the desire to
retain the FCS when advertising a VC label:
Parameter ID Length Description
0x?? 2 FCS Retention Indicator
Note: The next currently available parameter number is 0x0A [5].
This parameter number will be added to [5] if the timing permits
while it is still a draft, otherwise it will be assigned by IANA.
This note is to be removed once the assignment has been made.
The presence of this parameter ID in the VC FEC element indicates
that the egress PE requests 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 is simply an indication that the ingress PE
MAY retain the FCS. The sender MUST NOT retain the FCS if this
parameter ID is not present in the VC FEC element.
Since unknown parameter IDs are silently ignored [4], backwards
compatibility with systems that do not implement this document is
provided by requiring that the FCS is retained ONLY if the FCS
Retention Indicator has been included in the advertisements for
both directions on a pseudowire.
If the ingress PE recognizes the FCS Retention Indicator parameter
ID, but does not wish to retain the FCS, it need only issue its own
label mapping message for the opposite direction without including
the FCS Retention Indicator. This will prevent FCS retention in
either direction.
Malis et al Expires November 2004 [Page 3]
PWE3 FCS Retention May 2004
If PWE3 signaling [4] is not in use for a pseudowire, then whether
or not the FCS is to be retained MUST be identically provisioned in
both PEs at the pseudowire endpoints. If there is no provisioning
support for this option, the default behavior is to remove the FCS.
4. Signaling FCS Retention With L2TPv3-based Pseudowires
This section will be added in a subsequent revision.
5. Security Considerations
This mechanism enhances the data integrity of transparent Ethernet,
Frame Relay, and HDLC pseudowires, 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, it is clear that the payload was not altered
during its transmission through the network (or at least to the
accuracy of the original FCS; but that is demonstratably better
than no FCS at all).
Of course, nothing comes for free; this requires the additional
overhead of carrying the original FCS (in general, either two or
four octets per payload packet).
This signaling is backwards compatible and interoperable with
systems that do not implement this document.
6. Applicability Statement
In general, this document is intended to further extend the
applicability of the services defined by [1], [2], and [3] to make
them more suitable for use in deployments where data integrity is
an issue (or at least, is as much an issue as in the original
services that defined the FCS usage in the first place). There are
some situations where this extension is not necessary, such as
where the inner payloads have their own error-checking capabilities
(such as TCP). But for inner payloads that do rely on the error-
detecting capabilities of the link layer (such as SNA), this
additional protection can be invaluable.
When pseudowires are being used to connect 802.1 bridges, this
document allows pseudowires to comply with the requirement that all
media interconnecting 802.1 bridges have (at least) 32-bit FCS
protection.
Note that this document is one possible alternative for a service
provider to enhance the end-to-end data integrity of pseudowires.
Other mechanisms may include the use of end-to-end IPSec between
Malis et al Expires November 2004 [Page 4]
PWE3 FCS Retention May 2004
the PEs, or internal mechanisms in the P routers to assure the
integrity of packets as they are switched between ingress and
egress interfaces. Service providers may wish to compare the
relative strengths of each approach when planning their pseudowire
deployments; however, an argument can be made that it may be
wasteful for a 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 requires IANA to allocate a PWE3 Virtual Circuit FEC
element parameter ID [5].
8. References
[1] Martini, L. et al, "Encapsulation Methods for Transport of
Ethernet Frames Over IP and MPLS Networks", draft-ietf-pwe3-
ethernet-encap-06.txt, April 2004, work in progress
[2] Martini, L. et al, "Frame Relay Encapsulation over Pseudo-
Wires", draft-ietf-pwe3-frame-relay-02.txt, February 2004, work
in progress
[3] Martini, L. et al, "Encapsulation Methods for Transport of
PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-pwe3-
hdlc-ppp-encap-mpls-03.txt, April 2004, work in progress
[4] Martini, L. et al, "Transport of Layer 2 Frames Over MPLS",
draft-ietf-pwe3-control-protocol-06.txt, March 2004, work in
progress
[5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge to
Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-04.txt,
April 20034, work in progress
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
9. Authors' Addresses
Andrew G. Malis
Tellabs
90 Rio Robles Dr.
San Jose, CA 95134
Email: Andy.Malis@tellabs.com
David Allan
Malis et al Expires November 2004 [Page 5]
PWE3 FCS Retention May 2004
Nortel Networks
3500 Carling Ave.
Ottawa, Ontario, CANADA
Email: dallan@nortelnetworks.com
Nick Del Regno
MCI
400 International Parkway
Richardson, TX 75081
Email: nick.delregno@mci.com
Malis et al Expires November 2004 [Page 6]