[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-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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/