[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 4720

 Internet Draft                                         Andrew G. Malis
 Document: draft-ietf-pwe3-fcs-retention-02.txt                 Tellabs
 Expires:  March 2005                                       David Allan
                                                        Nortel Networks
                                                         Nick Del Regno
                                                                    MCI
                                                         September 2004
 
 
                    PWE3 Frame Check Sequence Retention
 
 IPR Statement
 
    By submitting this Internet-Draft, I certify that any applicable
    patent or other IPR claims of which I am aware have been disclosed,
    or will be disclosed, and any of which I become aware will be
    disclosed, in accordance with RFC 3668.
 
 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 a "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 2005                  [Page 1]
 

                           PWE3 FCS Retention            September 2004
 
 
    7. Applicability Statement.......................................6
    8. IANA Considerations...........................................6
    9. Acknowledgement...............................................7
    10. Normative References.........................................7
    11. Full Copyright Statement.....................................7
    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 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] 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 2005                  [Page 2]
 

                           PWE3 FCS Retention            September 2004
 
 
 
    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.
 
    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
 
 
 
 Malis et al               Expires March 2005                  [Page 3]
 

                           PWE3 FCS Retention            September 2004
 
 
    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 Virtual
    Circuit FEC element parameter ID used to signal the desire to
    retain the FCS when advertising a VC label:
 
       Parameter   ID Length    Description
            0x0A           4    FCS Retention Indicator
 
    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.
 
    The parameter includes a 16-bit FCS length field, which indicates
    the length of the original FCS being retained.  For Ethernet and
    ATM AAL5 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 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 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
    ID, 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 2005                  [Page 4]
 

                           PWE3 FCS Retention            September 2004
 
 
 
 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 and
    ATM AAL5 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
    accuracy of the original FCS; but that is demonstratably better
    than no FCS at all).
 
 
 Malis et al               Expires March 2005                  [Page 5]
 

                           PWE3 FCS Retention            September 2004
 
 
 
    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 requires IANA to allocate a PWE3 Virtual Circuit FEC
    element parameter ID [5].
 
    This specification also requires one value within the L2TP "Control
    Message Attribute Value Pairs" section to be assigned by IANA 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
 
 
 Malis et al               Expires March 2005                  [Page 6]
 

                           PWE3 FCS Retention            September 2004
 
 
    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-07.txt, July 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-08.txt, July 2004, work in
        progress
 
    [5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge to
        Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-05.txt,
        July 2004, work in progress
 
    [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.
 
    [7] J. Lau, M. Townsley, I. Goyret, "Layer Two Tunneling Protocol
        (Version 3)", work in progress, draft-ietf-l2tpext-l2tp-base-
        14.txt, June 2004.
 
    [8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet
        Assigned Numbers Authority (IANA) Considerations Update", RFC
        3438, December 2002.
 
 
 11. Full Copyright Statement
 
    Copyright (C) The Internet Society (2004).  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.
 
 
 Malis et al               Expires March 2005                  [Page 7]
 

                           PWE3 FCS Retention            September 2004
 
 
 
    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 2005                  [Page 8]
 

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/