idnits 2.17.1 draft-ietf-pwe3-fcs-retention-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 69. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 76. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 82. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2005) is 6791 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '10' is mentioned on line 93, but not defined == Missing Reference: '11' is mentioned on line 93, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-10 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-frame-relay-05 == Outdated reference: A later version (-09) exists of draft-ietf-pwe3-hdlc-ppp-encap-mpls-05 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-11 == Outdated reference: A later version (-09) exists of draft-ietf-l2tpext-pwe3-ethernet-03 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Andrew G. Malis 3 Document: draft-ietf-pwe3-fcs-retention-04.txt Tellabs 4 Expires: March 2006 David Allan 5 Nortel Networks 6 Nick Del Regno 7 MCI 8 September 2005 10 PWE3 Frame Check Sequence Retention 12 IPR Statement 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Status of this Memo 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts 29 as reference material or to cite them other than as "work in 30 progress". 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 This document defines a mechanism for preserving frame FCS through 41 Ethernet, Frame Relay, and HDLC pseudowires. 43 Table of Contents 45 1. Intellectual Property Statement...............................2 46 2. Specification of Requirements.................................2 47 3. Overview......................................................2 48 4. Signaling FCS Retention With MPLS-based Pseudowires...........4 49 5. Signaling FCS Retention With L2TPv3-based Pseudowires.........5 50 6. Security Considerations.......................................5 51 PWE3 FCS Retention September 2005 53 7. Applicability Statement.......................................6 54 8. IANA Considerations...........................................6 55 9. Acknowledgement...............................................7 56 10. Normative References.........................................7 57 11. Full Copyright Statement.....................................8 58 12. Authors' Addresses...........................................8 60 1. Intellectual Property Statement 62 The IETF takes no position regarding the validity or scope of any 63 Intellectual Property Rights or other rights that might be claimed 64 to pertain to the implementation or use of the technology described 65 in this document or the extent to which any license under such 66 rights might or might not be available; nor does it represent that 67 it has made any independent effort to identify any such rights. 68 Information on the procedures with respect to rights in RFC 69 documents can be found in BCP 78 and BCP 79. 71 Copies of IPR disclosures made to the IETF Secretariat and any 72 assurances of licenses to be made available, or the result of an 73 attempt made to obtain a general license or permission for the use 74 of such proprietary rights by implementers or users of this 75 specification can be obtained from the IETF on-line IPR repository 76 at http://www.ietf.org/ipr. 78 The IETF invites any interested party to bring to its attention any 79 copyrights, patents or patent applications, or other proprietary 80 rights that may cover technology that may be required to implement 81 this standard. Please address the information to the IETF at ietf- 82 ipr@ietf.org. 84 2. Specification of Requirements 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 88 this document are to be interpreted as described in RFC 2119 [6]. 90 3. Overview 92 The specifications for Ethernet, Frame Relay, HDLC, and PPP 93 pseudowire encapsulation [1] [2] [3] [9] [10] [11] include a mode 94 of use where frames are transparently delivered across the 95 pseudowire without any header or other alterations by the 96 pseudowire ingress or egress Provider Edge (PE). [Note that this 97 mode is inherent for HDLC and PPP Pseudowires.] 98 PWE3 FCS Retention September 2005 100 However, these specifications all specify that the original Frame 101 Check Sequence (FCS) be removed at ingress and regenerated at 102 egress, which means that the frames may be subject to unintentional 103 alteration during their traversal of the pseudowire from the 104 ingress to the egress PE. Thus, the pseudowire cannot be 105 absolutely guaranteed to be "transparent" in nature. 107 To be more precise, pseudowires, as currently defined, leave the 108 payload vulnerable to undetected errors caused by the encapsulating 109 network. Not only can a PW-aware device internally corrupt an 110 encapsulated payload, but ANY LSR or router in the path can corrupt 111 the encapsulated payload. In the event of such corruption, there is 112 no way to detect the corruption through the path of the pseudowire. 113 Further, because the FCS is calculated upon network egress, any 114 corruption will pass transparently through ALL Layer 2 switches 115 (Ethernet and Frame Relay) through which the packets travel. Only 116 at the endpoint, assuming the corrupted packet even reaches the 117 correct endpoint, can the packet be discarded, and depending on the 118 contents of the packet, the corruption may not ever be detected. 120 Not only does the encapsulation technique leave the payload 121 unprotected, it also subverts the error checking mechanisms already 122 in place in SP and customer networks by calculating FCS on 123 questionable data. 125 In a perfect network comprising perfect equipment, this is not an 126 issue. However, as there is no such thing, it is an issue. SPs 127 should have the option of saving overhead by yielding the ability 128 to detect faults. Equally, SPs should have the option to sacrifice 129 the overhead of carrying the original FCS end-to-end to ensure the 130 ability to detect faults in the encapsulating network. 132 This document defines such a mechanism to allow the ingress PE to 133 retain the original frame FCS on ingress to the network, and 134 relieves the egress PE of the task of regenerating the FCS. 136 This is an OPTIONAL mechanism for pseudowire implementations. For 137 interoperability with systems that do not implement this document, 138 the default behavior is that the FCS is removed at the ingress PE 139 and regenerated at the egress PE, as specified in [1], [2], and 140 [3]. 142 This capability may be used only with Ethernet pseudowires that use 143 "raw mode" [1], Frame Relay pseudowires that use "port mode" [2] 144 [3], and HDLC and PPP pseudowires [3]. 146 Note that this mechanism is not intended to carry errored frames 147 through the pseudowire; as usual, the FCS MUST be examined at the 148 PWE3 FCS Retention September 2005 150 ingress PE and errored frames MUST be discarded. The FCS MAY also 151 be examined by the egress PE; if this is done, errored frames MUST 152 be discarded. The egress PE MAY also wish to generate an alarm or 153 count the number of errored frames. 155 4. Signaling FCS Retention With MPLS-based Pseudowires 157 When using the signaling procedures in [4], there is a Pseudowire 158 Interface Parameter Sub-TLV type used to signal the desire to 159 retain the FCS when advertising a VC label [5]: 161 Parameter Length Description 162 0x0A 4 FCS Retention Indicator 164 The presence of this parameter indicates that the egress PE 165 requests the ingress PE to retain the FCS for the VC label being 166 advertised. It does not obligate the ingress PE to retain the FCS; 167 it is simply an indication that the ingress PE MAY retain the FCS. 168 The sender MUST NOT retain the FCS if this parameter is not present 169 in the VC FEC element. 171 The parameter includes a 16-bit FCS length field, which indicates 172 the length of the original FCS being retained. For Ethernet 173 pseudowires, this length will always be set to 4. For HDLC, PPP, 174 and Frame Relay pseudowires, this length will be set to either 2 or 175 4. Since the FCS length on these interfaces is a local setting, 176 retaining the FCS only makes sense if the FCS length is identical 177 on both ends of the pseudowire. Including the FCS length in this 178 parameter allows the PEs to ensure that the FCS is only retained 179 when it makes sense. 181 Since unknown parameters are silently ignored [4], backwards 182 compatibility with systems that do not implement this document is 183 provided by requiring that the FCS is retained ONLY if the FCS 184 Retention Indicator with an identical setting for the FCS length 185 has been included in the advertisements for both directions on a 186 pseudowire. 188 If the ingress PE recognizes the FCS Retention Indicator parameter, 189 but does not wish to retain the FCS with the indicated length, it 190 need only issue its own label mapping message for the opposite 191 direction without including the FCS Retention Indicator. This will 192 prevent FCS retention in either direction. 194 If PWE3 signaling [4] is not in use for a pseudowire, then whether 195 or not the FCS is to be retained MUST be identically provisioned in 196 both PEs at the pseudowire endpoints. If there is no provisioning 197 support for this option, the default behavior is to remove the FCS. 199 PWE3 FCS Retention September 2005 201 5. Signaling FCS Retention With L2TPv3-based Pseudowires 203 When using the signaling procedures in [7], the FCS Retention AVP, 204 Attribute Type L2TP-TBA-1, is used. 206 The Attribute Value field for this AVP has the following format: 208 0 1 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | FCS Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 The FCS Length is a 2-octet unsigned integer. 216 The presence of this AVP in an ICRQ or ICRP message indicates that 217 an LCCE (PE) requests its peer to retain FCS for the L2TP session 218 being established. If the receiving LCCE recognizes the AVP and 219 complies with the FCS retention request, it MUST include an FCS 220 Retention AVP as an acknowledgement in a corresponding ICRP or ICCN 221 message. FCS Retention is always bidirectional, thus FCS is only 222 retained if both LCCEs send an FCS Retention AVP during session 223 establishment. 225 The Attribute Value is a 16-bit FCS length field, which indicates 226 the length of the original FCS being retained. For Ethernet 227 pseudowires, this length will always be set to 4. For HDLC, PPP, 228 and Frame Relay pseudowires, this length will be set to either 2 or 229 4. Since the FCS length on these interfaces is a local setting, 230 retaining the FCS only makes sense if the FCS length is identical 231 on both ends of the pseudowire. Including the FCS length in this 232 AVP allows the PEs to ensure that the FCS is only retained when it 233 makes sense. 235 The Length of this AVP is 8. The M bit for this AVP MUST be set to 236 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0). 238 6. Security Considerations 240 This mechanism enhances the data integrity of transparent Ethernet, 241 Frame Relay, and HDLC pseudowires, because the original FCS, as 242 generated by the Customer Edge (CE), is included in the 243 encapsulation. When the encapsulated payload passes FCS checking 244 at the destination CE, it is clear that the payload was not altered 245 during its transmission through the network (or at least to the 246 PWE3 FCS Retention September 2005 248 accuracy of the original FCS; but that is demonstratably better 249 than no FCS at all). 251 Of course, nothing comes for free; this requires the additional 252 overhead of carrying the original FCS (in general, either two or 253 four octets per payload packet). 255 This signaling is backwards compatible and interoperable with 256 systems that do not implement this document. 258 7. Applicability Statement 260 In general, this document is intended to further extend the 261 applicability of the services defined by [1], [2], and [3] to make 262 them more suitable for use in deployments where data integrity is 263 an issue (or at least, is as much an issue as in the original 264 services that defined the FCS usage in the first place). There are 265 some situations where this extension is not necessary, such as 266 where the inner payloads have their own error-checking capabilities 267 (such as TCP). But for inner payloads that do rely on the error- 268 detecting capabilities of the link layer (such as SNA), this 269 additional protection can be invaluable. 271 When pseudowires are being used to connect 802.1 bridges, this 272 document allows pseudowires to comply with the requirement that all 273 media interconnecting 802.1 bridges have (at least) 32-bit FCS 274 protection. 276 Note that this document is one possible alternative for a service 277 provider to enhance the end-to-end data integrity of pseudowires. 278 Other mechanisms may include the use of end-to-end IPSec between 279 the PEs, or internal mechanisms in the P routers to assure the 280 integrity of packets as they are switched between ingress and 281 egress interfaces. Service providers may wish to compare the 282 relative strengths of each approach when planning their pseudowire 283 deployments; however, an argument can be made that it may be 284 wasteful for a SP to use an end-to-end integrity mechanism that is 285 STRONGER than the FCS generated by the source CE and checked by the 286 destination CE. 288 8. IANA Considerations 290 This document does not specify any new registries for IANA to 291 maintain. 293 Note that [5] allocates the FCS Retention Indicator interface 294 parameter, so no further IANA action is required. 296 PWE3 FCS Retention September 2005 298 This specification does require IANA to assign one value within the 299 L2TP "Control Message Attribute Value Pairs" section as per [8]. 300 The new AVP is encoded as L2TP-TBA-1 in this document, and should 301 be referred to in the IANA L2TP parameters registry as "FCS 302 Retention." 304 9. Acknowledgement 306 The authors would like to thank Mark Townsley for the text in 307 section 5. 309 10. Normative References 311 [1] Martini, L. et al, "Encapsulation Methods for Transport 312 of Ethernet Frames Over IP and MPLS Networks", draft-ietf- 313 pwe3-ethernet-encap-10.txt, June 2005, work in progress 315 [2] Martini, L. et al, "Frame Relay Encapsulation over 316 Pseudo-Wires", draft-ietf-pwe3-frame-relay-05.txt, April 317 2005, work in progress 319 [3] Martini, L. et al, "Encapsulation Methods for Transport 320 of PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf- 321 pwe3-hdlc-ppp-encap-mpls-05.txt, May 2005, work in progress 323 [4] Martini, L. et al, "Pseudowire Setup and Maintenance using the 324 Label Distribution Protocol", draft-ietf-pwe3-control-protocol- 325 17.txt, June 2005, work in progress 327 [5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge 328 to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation- 329 11.txt, June 2005, work in progress 331 [6] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", RFC 2119, March 1997. 334 [7] Lau, J., et al, "Layer Two Tunneling Protocol - Version 335 3 (L2TPv3)", RFC 3931, March 2005. 337 [8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 338 Internet Assigned Numbers Authority (IANA) 339 Considerations Update", RFC 3438, December 2002. 341 [9] Aggarwal, R. et al, "Transport of Ethernet Frames over L2TPv3", 342 draft-ietf-l2tpext-pwe3-ethernet-03.txt, April 2005, work in 343 progress 344 PWE3 FCS Retention September 2005 346 [10]Townsley, W. et al, "Frame-Relay over L2TPv3", draft-ietf- 347 l2tpext-pwe3-fr-06.txt, June 2005, work in progress 349 [11]Pignataro, C. et al, "HDLC Frames over L2TPv3", draft-ietf- 350 l2tpext-pwe3-hdlc-06.txt, June 2005, work in progress 352 11. Full Copyright Statement 354 Copyright (C) The Internet Society (2005). 356 This document is subject to the rights, licenses and restrictions 357 contained in BCP 78, and except as set forth therein, the authors 358 retain all their rights. 360 This document and the information contained herein are provided on 361 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 362 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 363 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 364 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 365 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 366 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 367 PARTICULAR PURPOSE. 369 12. Authors' Addresses 371 Andrew G. Malis 372 Tellabs 373 90 Rio Robles Dr. 374 San Jose, CA 95134 375 Email: Andy.Malis@tellabs.com 377 David Allan 378 Nortel Networks 379 3500 Carling Ave. 380 Ottawa, Ontario, CANADA 381 Email: dallan@nortelnetworks.com 383 Nick Del Regno 384 MCI 385 400 International Parkway 386 Richardson, TX 75081 387 Email: nick.delregno@mci.com