Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
draft-ietf-pwe3-fcs-retention-04
The information below is for an old version of the document that is already published as an RFC.
| Document | Type | RFC Internet-Draft (pwe3 WG) | |
|---|---|---|---|
| Authors | Andrew G. Malis , Nick Del Regno , David Allan | ||
| Last updated | 2013-03-02 (Latest revision 2005-09-09) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | RFC 4720 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Mark Townsley | ||
| Send notices to | stbryant@cisco.com, danny@arbor.net |
draft-ietf-pwe3-fcs-retention-04
Internet Draft Andrew G. Malis
Document: draft-ietf-pwe3-fcs-retention-04.txt Tellabs
Expires: March 2006 David Allan
Nortel Networks
Nick Del Regno
MCI
September 2005
PWE3 Frame Check Sequence Retention
IPR Statement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
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/1id-abstracts.html
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. Intellectual Property Statement...............................2
2. Specification of Requirements.................................2
3. Overview......................................................2
4. Signaling FCS Retention With MPLS-based Pseudowires...........4
5. Signaling FCS Retention With L2TPv3-based Pseudowires.........5
6. Security Considerations.......................................5
Malis et al Expires March 2006 [Page 1]
PWE3 FCS Retention September 2005
7. Applicability Statement.......................................6
8. IANA Considerations...........................................6
9. Acknowledgement...............................................7
10. Normative References.........................................7
11. Full Copyright Statement.....................................8
12. Authors' Addresses...........................................8
1. Intellectual Property Statement
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; nor does it 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.
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].
3. Overview
The specifications for Ethernet, Frame Relay, HDLC, and PPP
pseudowire encapsulation [1] [2] [3] [9] [10] [11] 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.]
Malis et al Expires March 2006 [Page 2]
PWE3 FCS Retention September 2005
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. 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 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
relieves the egress PE of the task of regenerating the FCS.
This is 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].
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].
Note that this mechanism is not intended to carry errored frames
through the pseudowire; as usual, the FCS MUST be examined at the
Malis et al Expires March 2006 [Page 3]
PWE3 FCS Retention September 2005
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.
4. Signaling FCS Retention With MPLS-based Pseudowires
When using the signaling procedures in [4], there is a Pseudowire
Interface Parameter Sub-TLV type used to signal 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 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 is not present
in the VC FEC element.
The parameter includes a 16-bit FCS length field, which indicates
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, this length will be set to either 2 or
4. Since the FCS length on these interfaces is a local setting,
retaining the FCS only makes sense if the FCS length is identical
on both ends of the pseudowire. Including the FCS length in this
parameter allows the PEs to ensure that the FCS is only retained
when it makes sense.
Since unknown parameters 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 with an identical setting for the FCS length
has been included in the advertisements for both directions on a
pseudowire.
If the ingress PE recognizes the FCS Retention Indicator parameter,
but does not wish to retain the FCS with the indicated length, 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.
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.
Malis et al Expires March 2006 [Page 4]
PWE3 FCS Retention September 2005
5. Signaling FCS Retention With L2TPv3-based Pseudowires
When using the signaling procedures in [7], the FCS Retention AVP,
Attribute Type L2TP-TBA-1, 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 indicates that
an LCCE (PE) requests its peer to 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, thus 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 indicates
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, this length will be set to either 2 or
4. Since the FCS length on these interfaces is a local setting,
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 allows the PEs to ensure that the FCS is only retained when it
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).
6. 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
Malis et al Expires March 2006 [Page 5]
PWE3 FCS Retention September 2005
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.
7. 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
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.
8. IANA Considerations
This document does not specify any new registries for IANA to
maintain.
Note that [5] allocates the FCS Retention Indicator interface
parameter, so no further IANA action is required.
Malis et al Expires March 2006 [Page 6]
PWE3 FCS Retention September 2005
This specification does require IANA to assign one value within the
L2TP "Control Message Attribute Value Pairs" section as per [8].
The new AVP is encoded as L2TP-TBA-1 in this document, and should
be referred to in the IANA L2TP parameters registry as "FCS
Retention."
9. Acknowledgement
The authors would like to thank Mark Townsley for the text in
section 5.
10. Normative References
[1] Martini, L. et al, "Encapsulation Methods for Transport
of Ethernet Frames Over IP and MPLS Networks", draft-ietf-
pwe3-ethernet-encap-10.txt, June 2005, work in progress
[2] Martini, L. et al, "Frame Relay Encapsulation over
Pseudo-Wires", draft-ietf-pwe3-frame-relay-05.txt, April
2005, 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-05.txt, May 2005, work in progress
[4] Martini, L. et al, "Pseudowire Setup and Maintenance using the
Label Distribution Protocol", draft-ietf-pwe3-control-protocol-
17.txt, June 2005, work in progress
[5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge
to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-
11.txt, June 2005, work in progress
[6] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[7] Lau, J., et al, "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", RFC 3438, December 2002.
[9] Aggarwal, R. et al, "Transport of Ethernet Frames over L2TPv3",
draft-ietf-l2tpext-pwe3-ethernet-03.txt, April 2005, work in
progress
Malis et al Expires March 2006 [Page 7]
PWE3 FCS Retention September 2005
[10]Townsley, W. et al, "Frame-Relay over L2TPv3", draft-ietf-
l2tpext-pwe3-fr-06.txt, June 2005, work in progress
[11]Pignataro, C. et al, "HDLC Frames over L2TPv3", draft-ietf-
l2tpext-pwe3-hdlc-06.txt, June 2005, work in progress
11. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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.
12. 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@nortelnetworks.com
Nick Del Regno
MCI
400 International Parkway
Richardson, TX 75081
Email: nick.delregno@mci.com
Malis et al Expires March 2006 [Page 8]