Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
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]