idnits 2.17.1 draft-ietf-trill-o-pw-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 30, 2014) is 3738 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) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Lucy Yong 2 INTERNET-DRAFT Donald Eastlake 3 Intended status: Proposed Standard Sam Aldrin 4 Huawei Technologies 5 Jon Hudson 6 Brocade 7 Expires: July 29, 2014 January 30, 2014 9 Transport of TRILL Using Pseudowires 10 12 Abstract 14 This document specifies how to interconnect a pair of TRILL 15 (Transparent Interconnection of Lots of Links) switch ports using 16 pseudowires under existing TRILL and PWE3 (Pseudowire Emulation End- 17 to-End) standards. 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Distribution of this document is unlimited. Comments should be sent 25 to the authors. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 39 Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Table of Contents 44 1. Introduction............................................3 45 1.1 Conventions used in this document......................3 47 2. PWE3 Interconnection of TRILL Switches..................4 48 2.1 PWE3 Type Independent Details..........................4 49 2.2 PPP PWE3 Transport of TRILL............................5 51 3. IANA Considerations.....................................7 52 4. Security Considerations.................................7 54 Appendix A: Use of Other Pseudowire Types..................8 56 Appendix Z: Change History................................10 58 Acknowledgements..........................................12 59 Normative References......................................12 60 Informative References....................................13 61 Authors' Addresses........................................14 63 1. Introduction 65 The TRILL (Transparent Interconnection of Lots of Links) protocol 66 [RFC6325] provides optimal pair-wise data frame routing without 67 configuration in multi-hop networks with arbitrary topology. TRILL 68 supports multipathing of both unicast and multicast traffic. Devices 69 that implement TRILL are called TRILL Switches or RBridges (Routing 70 Bridges). 72 Links between TRILL Switches can be based on arbitrary link 73 protocols, for example PPP [RFC6361], as well as Ethernet [RFC6325]. 74 A set of connected TRILL Switches together form a TRILL campus which 75 is bounded by end stations and layer 3 routers. 77 This document specifies how to interconnect a pair of TRILL Switch 78 ports using a pseudowire under existing TRILL and PWE3 (Pseudowire 79 Emulation End-to-End) standards. 81 1.1 Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in 86 [RFC2119]. 88 Acronyms used in this document include the following: 90 IS-IS - Intermediate System to Intermediate System [IS-IS] 92 MPLS - Multi-Protocol Label Switching 94 PPP - Point-to-Point Protocol [RFC1661] 96 PW - Pseudowire [RFC3985] 98 PWE3 - PW Emulation End-to-End 100 RBridge - Routing Bridge, an alternative name for a TRILL Switch 102 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 104 TRILL Switch - A device implementing the TRILL protocol 106 2. PWE3 Interconnection of TRILL Switches 108 When a pseudowire is used to interconnect a pair of TRILL Switch 109 ports, a PPP [RFC4618] pseudowire is used as described below. The 110 pseudowire between such ports can be signaled [RFC4447] or manually 111 configured. In this context, the TRILL Switch ports at the ends of 112 the pseudowire are acting as native service processing elements (NSP 113 [RFC3985]) and, assuming the pseudowires are over MPLS or IP 114 [RFC4023] networks, as label switched or IP routers at the TRILL 115 Switch ports. 117 Pseudowires provide transparent transport and the two TRILL Switch 118 ports appear directly interconnected with a transparent link. With 119 such an interconnection the TRILL adjacency over the link is 120 automatically discovered and established through TRILL IS-IS control 121 messages [RFC6327bis]. 123 A pseudowire is carried over a packet switched network tunnel 124 [RFC3985], for example, an MPLS or MPLS-TP label switched path tunnel 125 in MPLS networks. Either a signaling protocol or manual configuration 126 can be used to configure a label switched path tunnel between two 127 TRILL Switch ports. This application needs no additions to the 128 existing pseudowire standards. 130 2.1 PWE3 Type Independent Details 132 The sending pseudowire TRILL Switch port SHOULD map the inner 133 priority of the TRILL Data packets being sent to the Traffic Class 134 field of the pseudowire label [RFC5462] so as to minimize the 135 probability that higher priority TRILL Data packets will be discarded 136 due to excessive TRILL Data packets of lower priority. 138 TRILL IS-IS PDUs critical to establishing and maintaining adjacency 139 (Hello and MTU PDUs) SHOULD be sent with the MPLS Traffic Class that 140 calls for handling with the maximum priority. Other TRILL IS-IS PDUs 141 SHOULD be sent with the MPLS Traffic Class denoting the highest 142 priority that is less than the maximum priority. TRILL Data packets 143 SHOULD be sent with appropriate MPLS Traffic Classes, typically 144 mapped from the TRILL Data packet priority, such that TRILL Data 145 packet Traffic Classes denote priorities less than the priorities 146 used for TRILL IS-IS PDUs. This minimizes the probability of other 147 traffic interfering with these important control PDUs and causing 148 false loss of adjacency or other control problems. 150 If a pseudowire supports fragmentation and re-assembly (a feature 151 that has received little or no deployment), then there is no reason 152 to do TRILL MTU testing on it and the pseudowire will not be a 153 constraint on the TRILL campus wide MTU size (Sz) (see Section 4.3.1 155 [RFC6325]). If the pseudowire does not support fragmentation (the 156 more common case), then the available TRILL IS-IS packet payload size 157 over the pseudowire (taking into account MPLS encapsulation with a 158 control word) or some lower value, MUST be used in helping to 159 determine MTU size (Sz) (see Section 5 [ClearCorrect]). 161 An intervening MPLS label switched router or similar packet switched 162 network device has no awareness of TRILL. Such devices will not 163 change the TRILL Header hop count. 165 2.2 PPP PWE3 Transport of TRILL 167 For a PPP pseudowire (PW type = 0x0007), the two TRILL Switch ports 168 being connected are configured to form a pseudowire with PPP 169 encapsulation [RFC4618]. After the pseudowire is established and 170 TRILL use is negotiated within PPP, the two TRILL Switch ports appear 171 directly connected with a PPP link [RFC1661] [RFC6361]. 173 If pseudowire interconnection of two TRILL Switch ports is signaled 174 [RFC4447], the initiating TRILL Switch port MUST attempt the 175 connection set-up with pseudowire type PPP (0x0007). 177 Behavior for TRILL with a PPP pseudowire continues to follow that of 178 TRILL over PPP as specified in Section 3 of [RFC6361]. 180 The following figures show what a TRILL Data and TRILL IS-IS packet 181 look like over such a pseudowire in the MPLS case assuming no TRILL 182 Header extensions: 184 +-------------------------------+ 185 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 186 +-------------------------------+ 187 | PW Label | 4 octets 188 +-------------------------------+ 189 | Control Word | 4 octets 190 +-------------------------------+ 191 | PPP Header 0x005d | 2 octets 192 +-------------------------------+ 193 | TRILL Header | 4 octets 194 +-------------------------------+ 195 | Destination MAC Address | 6 octets 196 +-------------------------------+ 197 | Source MAC Address | 6 octets 198 +-------------------------------+ 199 | Data Label | 4 or 8 octets 200 +-------------------------------+ 201 | Payload Body | variable 202 +-------------------------------+ 204 Figure 1. TRILL Data Packet in Pseudowire 206 "Data Label" is the VLAN Label or Fine Grained Label [FGL] of the 207 payload. 209 +-------------------------------+ 210 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 211 +-------------------------------+ 212 | PW Label | 4 octets 213 +-------------------------------+ 214 | Control Word | 4 octets 215 +-------------------------------+ 216 | PPP Header 0x405d | 2 octets 217 +-------------------------------+ 218 | Common IS-IS Header | 8 octets 219 +-------------------------------+ 220 | IS-IS PDU Type Specifc Header | variable 221 +-------------------------------+ 222 | IS-IS TLVs | variable 223 +-------------------------------+ 225 Figure 2. TRILL IS-IS Packet in Pseudowire 227 The PPP Header fields (0x005d and 0x405d respectively) for TRILL Data 228 and IS-IS packets shown above are specified in [RFC6361]. 230 3. IANA Considerations 232 No IANA actions are required by this document. RFC Editor: Please 233 remove this section before publication. 235 4. Security Considerations 237 TRILL level secuirty mechanisms, such as the ability to use 238 authentication with TRILL IS-IS PDUs [RFC6325], are not affected by 239 link technology, such as the use of pseudowire links as specified in 240 this document. 242 Link security may be useful in improving TRILL campus security. 243 TRILL is transported over pseudowires as TRILL over PPP over 244 pseudowires, pseudowires are over MPLS or IP, and MPLS and IP are 245 over some lower level link technology. Thus link security below the 246 TRILL level for a pseudowire link could be provided by PPP security, 247 pseudowire security, MPLS or IP security, or security of the link 248 technolgy supporting MPLS or IP. 250 PPP TRILL security considerations are discussed in [RFC6361]. For 251 security considerations introduced by carrying PPP TRILL links over 252 pseudowires, see [RFC3985], which discusses the risks introduced by 253 sending protocols that previously assumed a point-to-point link on a 254 pseudo wire built on a packet switched network (PSN). However, the 255 PPP layer in TRILL transport by pseudowire is somewhat vestigial and 256 intended primarily as a convenient way to use existing PPP code 257 points to identify TRILL data packets and TRILL IS-IS packets. 258 Furthermore, existing PPP security standards are arguably 259 questionable in terms of current security criteria. For these 260 reasons, it is NOT RECOMMENDED to use PPP security in the transport 261 of TRILL by pseudowires as sepecified in this document. 263 It is RECOMMENDED that link security be provided at the layers 264 supporting pseudowires transporting TRILL, that is, at the MPLS or IP 265 layer or the link layer transporting MPLS or IP. 267 For applications involving sensitive data, end-to-end security should 268 always be considered, in addition to link security, to provide 269 security in depth. In this context, such end-to-end security should 270 be between the end stations involved so as to protect the entire path 271 to, through, and from the TRILL campus. 273 For general TRILL protocol security considerations, see [RFC6325]. 275 Appendix A: Use of Other Pseudowire Types 277 This informational Appendix briefly discusses use of pseudowire types 278 other than PPP for the transport of TRILL. 280 The use of Ethernet pseudowires [RFC4448] was examined by the authors 281 and would be possible without change to such pseudowires; however, 282 this would require an additional 12 or 16 bytes per packet within the 283 payload being transmitted over the pseudowire as shown in the 284 following figures for a TRILL Data and TRILL IS-IS packet over such 285 an Ethernet pseudowire in the MPLS case assuming no TRILL Header 286 extensions (compare with Figures 1 and 2): 288 +-------------------------------+ 289 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 290 +-------------------------------+ 291 | PW Label | 4 octets 292 +-------------------------------+ 293 | Optional Control Word | 4 octets 294 +-------------------------------+ 295 | TRILL Hop Dest. MAC Address | 6 octets 296 +-------------------------------+ 297 | TRILL Hop Source MAC Address | 6 octets 298 +-------------------------------+ 299 |Optional VLAN and/or other tags| variable 300 +-------------------------------+ 301 | TRILL Ethertype (0x22f3) | 2 octets 302 +-------------------------------+ 303 | TRILL Header | 4 octets 304 +-------------------------------+ 305 | Destination MAC Address | 6 octets 306 +-------------------------------+ 307 | Source MAC Address | 6 octets 308 +-------------------------------+ 309 | Data Label | 4 or 8 octets 310 +-------------------------------+ 311 | Payload Body | variable 312 +-------------------------------+ 314 Figure 3. TRILL Data Packet in Ethernet Pseudowire 316 "Data Label" is the VLAN Label or Fine Grained Label [FGL] of the 317 payload. 319 +-------------------------------+ 320 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 321 +-------------------------------+ 322 | PW Label | 4 octets 323 +-------------------------------+ 324 | Optional Control Word | 4 octets 325 +-------------------------------+ 326 | TRILL Hop Dest. MAC Address | 6 octets 327 +-------------------------------+ 328 | TRILL Hop Source MAC Address | 6 octets 329 +-------------------------------+ 330 |Optional VLAN and/or other tags| variable 331 +-------------------------------+ 332 |Layer 2 IS-IS Ethertype 0x22f4 | 2 octets 333 +-------------------------------+ 334 | Commmon IS-IS Header | 8 octets 335 +-------------------------------+ 336 | IS-IS PDU Type Specifc Header | variable 337 +-------------------------------+ 338 | IS-IS TLVs | variable 339 +-------------------------------+ 341 Figure 4. TRILL IS-IS Packet in Ethernet Pseudowire 343 It would also be possible to specify a new pseudowire type for TRILL 344 traffic but the authors feel that any efficiency gain over PPP 345 pseudowires would be too small to be worth the complexity of adding 346 such a specification. Furthermore using PPP pseudowire encoding means 347 that any traffic dissector that understands TRILL PPP encoding 348 [RFC6361] and understands PPP pseudowires [RFC4618] will 349 automatically be able to recursively decode TRILL transported by 350 pseudowire. 352 Appendix Z: Change History 354 RFC Editor Note: Please remove this appendix prior to publication. 356 From -00 to -01 358 Add information on Traffic Classes that should be used for TRILL IS- 359 IS PDUs. 361 Other changes to resolve WG Last Call comments: 363 Change title from "TRILL Over Psuedowires". 365 Change "Class of Service" to "Traffic Class". 367 Expand informational paragraph about the consideration of using 368 other pseudowire types for the transport of TRILL and make that 369 paragraph into Appendix A. 371 Add this Change History Appendix Z. 373 From -01 to -02 375 Add packet diagrams. 377 Minor editing changes. 379 From -02 to -03 381 Editorial and minor Security Considerations changes based on the 382 Shepherd review by Erik Nordmark. See 383 http://www.ietf.org/mail-archive/web/trill/current/msg06029.html 384 and ensuing conversation. 386 From -03 to -04 388 Security Considerations changes based on SECDIR review. 390 Minor Editorial change to the first sentence of Section 1 based on 391 GENART review. 393 Add final sentence to first paragraph of Section 2.1 to resolve 394 COMMENT by Barry Leiba. 396 From -04 to -05 398 Assorted changes resulting from IESG review: 400 Replace "autoconfigured" with "signaled". 402 Clarify that it is the inner TRILL Data packet priority that is 403 used to determine pseudowire Traffic Class and that the priority is 404 mapped to the Traffic Class. 406 Clarify that if Ethernet pseudowires were used no change would be 407 required in the Ethernet pseudowire standard. 409 Expand "Sz" to "MTU size (Sz)". 411 Note that pseudowire fragmentation has little if any deployment. 413 Minor editorial improvements. 415 From -05 to -06 417 Change wording concerning suggested Traffic Classes for TRILL IS-IS 418 and TRILL Data packets in Section 2.1. 420 Acknowledgements 422 Thanks for the valuable comments from the following who are listed in 423 alphabetic order: 425 Stewart Bryant, Stephen Farrell, Brain Haberman, Christer 426 Holmberg, Joel Jaeggli, Barry Leiba, Erik Nordmark, Yaron Sheffer, 427 and Yaakov (J) Stein 429 The document was prepared in raw nroff. All macros used were defined 430 within the source file. 432 Normative References 434 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 435 STD 51, RFC 1661, July 1994. 437 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, March 1997. 440 [RFC4447] - Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 441 G. Heron, "Pseudowire Setup and Maintenance Using the Label 442 Distribution Protocol (LDP)", RFC 4447, April 2006. 444 [RFC4618] - Martini, L., "Encapsulation Methods for Transport of 445 PPP/High-Level Data Link Control (HDLC) over MPLS Networks", 446 BCP 116, RFC 4618, September 2006. 448 [RFC5462] - Andersson, L. and R. Asati, "Multiprotocol Label 449 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to 450 "Traffic Class" Field", RFC 5462, February 2009. 452 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 453 Ghanwani, "Routing Bridges (RBridges): Base Protocol 454 Specification", RFC6325, July 2011. 456 [RFC6361] - Carlson, J., and D. Eastlake, "PPP Transparent 457 Interconnection of Lots of Links (TRILL) Protocol Control 458 Protocol", RFC6361, August 2011. 460 [ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, and 461 A. Banerjee, "TRILL: Clarifications, Corrections, and Updates", 462 draft-ietf-trill-clear-correct, in RFC Editor's queue. 464 [FGL] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 465 "TRILL (Transparent Interconnection of Lots of Links): Fine- 466 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 467 Editor's queue. 469 Informative References 471 [IS-IS] - International Organization for Standardization, 472 "Intermediate system to Intermediate system intra-domain 473 routing information exchange protocol for use in conjunction 474 with the protocol for providing the connectionless-mode Network 475 Service (ISO 8473)", ISO/IEC10589:2002, Second Edition, Nov 476 2002 478 [RFC3985] - Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation 479 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 481 [RFC4023] - Worster, T., Rekhter, Y., and E. Rosen, Ed., 482 "Encapsulating MPLS in IP or Generic Routing Encapsulation 483 (GRE)", RFC 4023, March 2005. 485 [RFC4448] - Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 486 "Encapsulation Methods for Transport of Ethernet over MPLS 487 Networks", RFC 4448, April 2006. 489 [RFC6327bis] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Howard, 490 Y., and V. Manral, "TRILL: Adjacency", draft-ietf-trill- 491 rfc6327bis, work in progress. 493 Authors' Addresses 495 Lucy Yong 496 Huawei Technologies 497 5340 Legacy Drive 498 Plano, TX 75025 USA 500 Phone: +1-469-227-5837 501 Email: lucy.yong@huawei.com 503 Donald E. Eastlake, 3rd 504 Huawei Technologies 505 155 Beaver Street 506 Milford, MA 01757 USA 508 Phone: +1-508-333-2270 509 Email: d3e3e3@gmail.com 511 Sam Aldrin 512 Huawei Technologies 513 2330 Central Expressway 514 Santa Clara, CA 95050 USA 516 Phone: +1-408-330-4517 517 Email: sam.aldrin@huawei.com 519 Jon Hudson 520 Brocade 521 130 Holger Way 522 San Jose, CA 95134 USA 524 Phone: +1-408-333-4062 525 jon.hudson@gmail.com 527 Copyright and IPR Provisions 529 Copyright (c) 2014 IETF Trust and the persons identified as the 530 document authors. All rights reserved. 532 This document is subject to BCP 78 and the IETF Trust's Legal 533 Provisions Relating to IETF Documents 534 (http://trustee.ietf.org/license-info) in effect on the date of 535 publication of this document. Please review these documents 536 carefully, as they describe your rights and restrictions with respect 537 to this document. Code Components extracted from this document must 538 include Simplified BSD License text as described in Section 4.e of 539 the Trust Legal Provisions and are provided without warranty as 540 described in the Simplified BSD License. The definitive version of 541 an IETF Document is that published by, or under the auspices of, the 542 IETF. Versions of IETF Documents that are published by third parties, 543 including those that are translated into other languages, should not 544 be considered to be definitive versions of IETF Documents. The 545 definitive version of these Legal Provisions is that published by, or 546 under the auspices of, the IETF. Versions of these Legal Provisions 547 that are published by third parties, including those that are 548 translated into other languages, should not be considered to be 549 definitive versions of these Legal Provisions. For the avoidance of 550 doubt, each Contributor to the IETF Standards Process licenses each 551 Contribution that he or she makes as part of the IETF Standards 552 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 553 language to the contrary, or terms, conditions or rights that differ 554 from or are inconsistent with the rights and licenses granted under 555 RFC 5378, shall have any effect and shall be null and void, whether 556 published or posted by such Contributor, or included with or in such 557 Contribution.