idnits 2.17.1 draft-ietf-trill-o-pw-02.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 (November 14, 2013) is 3816 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: May 13, 2014 November 14, 2013 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 55 Appendix Z: Change History................................10 57 Acknowledgements..........................................11 58 Normative References......................................11 59 Informative References....................................12 60 Authors' Addresses........................................13 62 1. Introduction 64 The IETF has standardized the TRILL (Transparent Interconnection of 65 Lots of Links) protocol [RFC6325] that provides optimal pair-wise 66 data frame routing without configuration in multi-hop networks with 67 arbitrary topology. TRILL supports multipathing of both unicast and 68 multicast traffic. Devices that implement TRILL are called TRILL 69 Switches or RBridges (Routing Bridges). 71 Links between TRILL Switches can be based on arbitrary link 72 protocols, for example PPP [RFC6361], as well as Ethernet [RFC6325]. 73 A set of connected TRILL Switches together form a TRILL campus which 74 is bounded by end stations and layer 3 routers. 76 This document specifies how to interconnect a pair of TRILL Switch 77 ports using a pseudowire under existing TRILL and PWE3 (Pseudowire 78 Emulation End-to-End) standards. 80 1.1 Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 Acronyms used in this document include the following: 88 IS-IS - Intermediate System to Intermediate System [IS-IS] 90 MPLS - Multi-Protocol Label Switching 92 PPP - Point-to-Point Protocol [RFC1661] 94 PW - Pseudowire [RFC3985] 96 PWE3 - PW Emulation End-to-End 98 RBridge - Routing Bridge, an alternative name for a TRILL Switch 100 TRILL - Transparent Interconnection of Lots of Links [RFC6325] 102 TRILL Switch - A device implementing the TRILL protocol 104 2. PWE3 Interconnection of TRILL Switches 106 When a pseudowire is used to interconnect a pair of TRILL Switch 107 ports, a PPP [RFC4618] pseudowire is used as described below. The 108 pseudowire between such ports can be auto-configured [RFC4447] or 109 manually configured. In this context, the TRILL Switch ports at the 110 ends of the pseudowire are acting as native service processing 111 elements (NSP [RFC3985]) and, assuming the pseudowires are over MPLS 112 or IP [RFC4023] networks, as label switched or IP routers at the 113 TRILL Switch ports. 115 Pseudowires provide transparent transport and the two TRILL Switch 116 ports appear directly interconnected with a transparent link. With 117 such an interconnection the TRILL adjacency over the link is 118 automatically discovered and established through TRILL IS-IS control 119 messages [RFC6327bis]. 121 A pseudowire is carried over a packet switched network tunnel 122 [RFC3985]. For example, an MPLS or MPLS-TP label switched path 123 tunnel in MPLS networks. Either a signaling protocol or manual 124 configuration can be used to configure a label switched path tunnel 125 between two TRILL Switch ports. This application needs no additions 126 to the existing pseudowire standards. 128 2.1 PWE3 Type Independent Details 130 The sending pseudowire TRILL Switch port MUST copy the priority of 131 the TRILL Data packets being sent to the 3-bit Traffic Class field of 132 the pseudowire label [RFC5462] so the priority will be visible to 133 pseudowire transit devices and they can take the priority into 134 account. TRILL IS-IS PDUs critical to establishing and maintaining 135 adjacency (Hello and MTU PDUs) SHOULD be send with Traffic Class 7 136 while other TRILL IS-IS PDUs SHOULD be sent with Traffic Class 6. 138 If a pseudowire supports fragmentation and re-assembly, there is no 139 reason to do TRILL MTU testing on it and the pseudowire will not be a 140 constraint on the TRILL campus wide Sz (see Section 4.3.1 [RFC6325]). 141 If the pseudowire does not support fragmentation, then the available 142 TRILL IS-IS packet payload size over the pseudowire (taking into 143 account MPLS encapsulation with a control word) or some lower value, 144 MUST be used in helping to determine Sz (see Section 5 145 [ClearCorrect]). 147 An intervening MPLS label switched router or similar packet switched 148 network device has no awareness of TRILL. Such devices will not 149 change the TRILL Header hop count. 151 2.2 PPP PWE3 Transport of TRILL 153 For a PPP pseudowire (PW type = 0x0007), the two TRILL Switch ports 154 being connected are configured to form a pseudowire with PPP 155 encapsulation [RFC4618]. After the pseudowire is established and 156 TRILL use is negotiated within PPP, the two TRILL Switch ports appear 157 directly connected with a PPP link [RFC1661] [RFC6361]. 159 If pseudowire interconnection of two TRILL Switch ports is auto- 160 configured [RFC4447], the initiating TRILL Switch port MUST attempt 161 the connection set-up with pseudowire type PPP (0x0007). 163 Behavior for TRILL with a PPP pseudowire continues to follow that of 164 TRILL over PPP as specified in Section 3 of [RFC6361]. 166 The following figures show what a TRILL Data and TRILL IS-IS packet 167 look like over such a pseudowire in the MPLS case assuming no TRILL 168 Header extensions: 170 +-------------------------------+ 171 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 172 +-------------------------------+ 173 | PW Label | 4 octets 174 +-------------------------------+ 175 | Control Word | 4 octets 176 +-------------------------------+ 177 | PPP Header 0x005d | 2 octets 178 +-------------------------------+ 179 | TRILL Header | 4 octets 180 +-------------------------------+ 181 | Destination MAC Address | 6 octets 182 +-------------------------------+ 183 | Source MAC Address | 6 octets 184 +-------------------------------+ 185 | Data Label | 4 or 8 octets 186 +-------------------------------+ 187 | Payload Body | variable 188 +-------------------------------+ 190 Figure 1. TRILL Data Packet in Pseudowire 192 "Data Label" is the VLAN Label or Fine Grained Label [FGL] of the 193 payload. 195 +-------------------------------+ 196 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 197 +-------------------------------+ 198 | PW Label | 4 octets 199 +-------------------------------+ 200 | Control Word | 4 octets 201 +-------------------------------+ 202 | PPP Header 0x405d | 2 octets 203 +-------------------------------+ 204 | Common IS-IS Header | 8 octets 205 +-------------------------------+ 206 | IS-IS PDU Type Specifc Header | variable 207 +-------------------------------+ 208 | IS-IS TLVs | variable 209 +-------------------------------+ 211 Figure 2. TRILL IS-IS Packet in Pseudowire 213 3. IANA Considerations 215 No IANA actions are required by this document. RFC Editor: Please 216 remove this section before publication. 218 4. Security Considerations 220 For PPP link TRILL security considerations, see [RFC6361]. 222 For security considerations introduced by carrying PPP TRILL links 223 over pseudowires, see [RFC3985]. 225 Not all implementations need to include specific security mechanisms 226 at the pseudowire layer, for example if they are designed to be 227 deployed only in cases where the networking environment is trusted or 228 where other layers provide adequate security. A complete enumeration 229 of possible deployment scenarios and associated threats and options 230 is not possible and is outside the scope of this document. For 231 applications involving sensitive data, end-to-end security should 232 always be considered, in addition to link security, to provide 233 security in depth. In this context, such end-to-end security should 234 be between the end stations involved so as to protect the entire path 235 to, through, and from the TRILL campus. 237 For general TRILL protocol security considerations, see [RFC6325]. 239 Appendix A: Use of Other Pseudowire Types 241 This informational Appendix briefly discusses use of pseudowire types 242 other than PPP for the transport of TRILL. 244 The use of Ethernet pseudowires [RFC4448] was examined by the authors 245 and would be possible; however, they would require an additional 12 246 or 16 bytes per packet as shown in the following figures for a TRILL 247 Data and TRILL IS-IS packet over such an Ethernet pseudowire in the 248 MPLS case assuming no TRILL Header extensions (compare with Figures 1 249 and 2): 251 +-------------------------------+ 252 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 253 +-------------------------------+ 254 | PW Label | 4 octets 255 +-------------------------------+ 256 | Optional Control Word | 4 octets 257 +-------------------------------+ 258 | TRILL Hop Dest. MAC Address | 6 octets 259 +-------------------------------+ 260 | TRILL Hop Source MAC Address | 6 octets 261 +-------------------------------+ 262 |Optional VLAN and/or other tags| variable 263 +-------------------------------+ 264 | TRILL Ethertype (0x22f3) | 2 octets 265 +-------------------------------+ 266 | TRILL Header | 4 octets 267 +-------------------------------+ 268 | Destination MAC Address | 6 octets 269 +-------------------------------+ 270 | Source MAC Address | 6 octets 271 +-------------------------------+ 272 | Data Label | 4 or 8 octets 273 +-------------------------------+ 274 | Payload Body | variable 275 +-------------------------------+ 277 Figure 3. TRILL Data Packet in Ethernet Pseudowire 279 "Data Label" is the VLAN Label or Fine Grained Label [FGL] of the 280 payload. 282 +-------------------------------+ 283 | Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label) 284 +-------------------------------+ 285 | PW Label | 4 octets 286 +-------------------------------+ 287 | Optional Control Word | 4 octets 288 +-------------------------------+ 289 | TRILL Hop Dest. MAC Address | 6 octets 290 +-------------------------------+ 291 | TRILL Hop Source MAC Address | 6 octets 292 +-------------------------------+ 293 |Optional VLAN and/or other tags| variable 294 +-------------------------------+ 295 |Layer 2 IS-IS Ethertype 0x22f4 | 2 octets 296 +-------------------------------+ 297 | Commmon IS-IS Header | 8 octets 298 +-------------------------------+ 299 | IS-IS PDU Type Specifc Header | variable 300 +-------------------------------+ 301 | IS-IS TLVs | variable 302 +-------------------------------+ 304 Figure 4. TRILL IS-IS Packet in Ethernet Pseudowire 306 It would also be possible to specify a new pseudowire type for TRILL 307 traffic but the authors feel that any efficiency gain over PPP 308 pseudowires would be too small to be worth the complexity of adding 309 such a specification. Furthermore using PPP pseudowire encoding means 310 that any traffic dissector that understands TRILL PPP encoding 311 [RFC6361] and understands PPP pseudowires [RFC4618] will 312 automatically be able to recursively decode TRILL transported by 313 pseudowire. 315 Appendix Z: Change History 317 From -00 to -01 319 Add information on Traffic Classes that should be used for TRILL IS- 320 IS PDUs. 322 Other changes to resolve WG Last Call comments: 324 Change title from "TRILL Over Psuedowires". 326 Change "Class of Service" to "Traffic Class". 328 Expand informational paragraph about the consideration of using 329 other pseudowire types for the transport of TRILL and make that 330 paragraph into Appendix A. 332 Add this Change History Appendix Z. 334 From -01 to -02 336 Add packet diagrams. 338 Minor editing changes. 340 Acknowledgements 342 Thanks for the valuable comments from the following: 344 Yaakov (J) Stein 346 The document was prepared in raw nroff. All macros used were defined 347 within the source file. 349 Normative References 351 [RFC1661] - Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", 352 STD 51, RFC 1661, July 1994. 354 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC4447] - Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 358 G. Heron, "Pseudowire Setup and Maintenance Using the Label 359 Distribution Protocol (LDP)", RFC 4447, April 2006. 361 [RFC4618] - Martini, L., "Encapsulation Methods for Transport of 362 PPP/High-Level Data Link Control (HDLC) over MPLS Networks", 363 BCP 116, RFC 4618, September 2006. 365 [RFC5462] - Andersson, L. and R. Asati, "Multiprotocol Label 366 Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to 367 "Traffic Class" Field", RFC 5462, February 2009. 369 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 370 Ghanwani, "Routing Bridges (RBridges): Base Protocol 371 Specification", RFC6325, July 2011. 373 [RFC6361] - Carlson, J., and D. Eastlake, "PPP Transparent 374 Interconnection of Lots of Links (TRILL) Protocol Control 375 Protocol", RFC6361, August 2011. 377 [ClearCorrect] - Eastlake, D., M. Zhang, A. Ghanwani, V. Manral, and 378 A. Banerjee, "TRILL: Clarifications, Corrections, and Updates", 379 draft-ietf-trill-clear-correct, in RFC Editor's queue. 381 [FGL] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 382 "TRILL (Transparent Interconnection of Lots of Links): Fine- 383 Grained Labeling", draft-ietf-trill-fine-labeling, in RFC 384 Editor's queue. 386 Informative References 388 [IS-IS] - International Organization for Standardization, 389 "Intermediate system to Intermediate system intra-domain 390 routing information exchange protocol for use in conjunction 391 with the protocol for providing the connectionless-mode Network 392 Service (ISO 8473)", ISO/IEC10589:2002, Second Edition, Nov 393 2002 395 [RFC3985] - Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation 396 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 398 [RFC4023] - Worster, T., Rekhter, Y., and E. Rosen, Ed., 399 "Encapsulating MPLS in IP or Generic Routing Encapsulation 400 (GRE)", RFC 4023, March 2005. 402 [RFC4448] - Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 403 "Encapsulation Methods for Transport of Ethernet over MPLS 404 Networks", RFC 4448, April 2006. 406 [RFC6327bis] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Howard, 407 Y., and V. Manral, "TRILL: Adjacency", draft-ietf-trill- 408 rfc6327bis, work in progress. 410 Authors' Addresses 412 Lucy Yong 413 Huawei Technologies 414 5340 Legacy Drive 415 Plano, TX 75025 USA 417 Phone: +1-469-227-5837 418 Email: lucy.yong@huawei.com 420 Donald E. Eastlake, 3rd 421 Huawei Technologies 422 155 Beaver Street 423 Milford, MA 01757 USA 425 Phone: +1-508-333-2270 426 Email: d3e3e3@gmail.com 428 Sam Aldrin 429 Huawei Technologies 430 2330 Central Expressway 431 Santa Clara, CA 95050 USA 433 Phone: +1-408-330-4517 434 Email: sam.aldrin@huawei.com 436 Jon Hudson 437 Brocade 438 130 Holger Way 439 San Jose, CA 95134 USA 441 Phone: +1-408-333-4062 442 jon.hudson@gmail.com 444 Copyright and IPR Provisions 446 Copyright (c) 2013 IETF Trust and the persons identified as the 447 document authors. All rights reserved. 449 This document is subject to BCP 78 and the IETF Trust's Legal 450 Provisions Relating to IETF Documents 451 (http://trustee.ietf.org/license-info) in effect on the date of 452 publication of this document. Please review these documents 453 carefully, as they describe your rights and restrictions with respect 454 to this document. Code Components extracted from this document must 455 include Simplified BSD License text as described in Section 4.e of 456 the Trust Legal Provisions and are provided without warranty as 457 described in the Simplified BSD License. The definitive version of 458 an IETF Document is that published by, or under the auspices of, the 459 IETF. Versions of IETF Documents that are published by third parties, 460 including those that are translated into other languages, should not 461 be considered to be definitive versions of IETF Documents. The 462 definitive version of these Legal Provisions is that published by, or 463 under the auspices of, the IETF. Versions of these Legal Provisions 464 that are published by third parties, including those that are 465 translated into other languages, should not be considered to be 466 definitive versions of these Legal Provisions. For the avoidance of 467 doubt, each Contributor to the IETF Standards Process licenses each 468 Contribution that he or she makes as part of the IETF Standards 469 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 470 language to the contrary, or terms, conditions or rights that differ 471 from or are inconsistent with the rights and licenses granted under 472 RFC 5378, shall have any effect and shall be null and void, whether 473 published or posted by such Contributor, or included with or in such 474 Contribution.