RFC 7173
Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires
RFC 7173 📄💖 Transparent Interconnection of Lots of Links (TRILL) Transport Using Pseudowires
Title block tea ☕🎀: This one is from the IETF (Internet Engineering Task Force), numbered RFC 7173, and it's a Standards Track doc, so it's an actual Internet standard, not just a vibe. The authors are L. Yong, D. Eastlake 3rd, and S. Aldrin (all from Huawei), plus J. Hudson (from Brocade). It was published in May 2014, and it has ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.
Abstract ✨
Okay so this doc is all about how to connect a pair of TRILL switch ports using pseudowires 🧚, as long as you stick to the existing TRILL and PWE3 (Pseudowire Emulation End-to-End) standards. Iconic behavior, honestly 💅.
Status of This Memo 📋
Bestie, this is an Internet Standards Track document 🔥. It's a product of the IETF, which means it has the consensus of the whole IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more about Internet Standards, check Section 2 of RFC 5741. You can find the current status, any errata, and how to send feedback at http://www.rfc-editor.org/info/rfc7173 🌸.
Copyright Notice 🌈
This is Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved 💜. The doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood when it was published. Read those carefully, because they explain your rights and restrictions 🙈. Any Code Components pulled out of this doc must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🍓.
Table of Contents 🗂️
1. Introduction.....................................................2
1.1. Conventions Used in This Document...........................2
2. PWE3 Interconnection of TRILL Switches...........................3
2.1. PWE3 Type-Independent Details...............................3
2.2. PPP PWE3 Transport of TRILL.................................4
3. Security Considerations..........................................6
Appendix A. Use of Other Pseudowire Types ..........................7
Acknowledgements ...................................................8
Normative References ...............................................9
Informative References ............................................101. Introduction ✨
Okay, big picture 🖼️. The TRILL protocol, from [RFC6325], gives you optimal pair-wise data frame routing with zero configuration in multi-hop networks with arbitrary topology 👑. It also supports multipathing for both unicast and multicast traffic 🦋. Devices that implement TRILL are called TRILL switches, or Routing Bridges (RBridges) 💅.
Links between TRILL switches can use all kinds of link protocols. For example, there's PPP [RFC6361], and there's Ethernet [RFC6325] too 🎀. A group of connected TRILL switches forms a TRILL campus, and that campus is bounded by end stations and Layer 3 routers 🧚.
So this document says how to interconnect a pair of TRILL switch ports using a pseudowire, under the existing TRILL and PWE3 (Pseudowire Emulation End-to-End) standards 💖.
1.1. Conventions Used in This Document 🔤
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Yes, those capital words are the important ones, so pay attention 🙈💀.
Here are the acronyms you'll see:
- IS-IS - Intermediate System to Intermediate System [IS-IS]
- MPLS - Multi-Protocol Label Switching
- PPP - Point-to-Point Protocol [RFC1661]
- PW - Pseudowire [RFC3985]
- PWE3 - PW Emulation End-to-End
- RBridge - Routing Bridge, an alternative name for a TRILL switch
- TRILL - Transparent Interconnection of Lots of Links [RFC6325]
- TRILL Switch - A device implementing the TRILL protocol
2. PWE3 Interconnection of TRILL Switches 🦋
When you use a pseudowire to link a pair of TRILL switch ports, you use a PPP [RFC4618] pseudowire, as described below 🎀. The pseudowire between those ports can be signaled [RFC4447] or manually configured, your choice 🫶. The TRILL switch ports at each end act as native service processing (NSP) elements [RFC3985]. And if the pseudowires run over MPLS or IP [RFC4023] networks, those ports also act as label switched or IP routers 🔥.
Pseudowires give you transparent transport, so the two TRILL switch ports look like they're directly interconnected with a transparent link ✨. With that setup, the TRILL adjacency over the link gets discovered and established automatically, through TRILL IS-IS control messages [RFC7177] 🌈.
A pseudowire rides over a packet switched network tunnel [RFC3985], like an MPLS or MPLS-TP label switched path tunnel in MPLS networks 🧚. Either a signaling protocol or manual configuration can set up that label switched path tunnel between two TRILL switch ports 💅. This application doesn't need any additions to the existing pseudowire standards, which is honestly so clean 😭.
2.1. PWE3 Type-Independent Details 💜
The sending pseudowire TRILL switch port SHOULD map the inner priority of the TRILL Data packets it sends to the Traffic Class field of the pseudowire label [RFC5462]. The goal is to minimize the chance that higher priority TRILL Data packets get discarded because there are too many lower priority TRILL Data packets 🔥.
TRILL IS-IS PDUs that are critical to establishing and maintaining adjacency (Hello and MTU PDUs) SHOULD be sent with the MPLS Traffic Class that calls for handling at the maximum priority 👑. Other TRILL IS-IS PDUs SHOULD be sent with the MPLS Traffic Class denoting the highest priority that is less than the maximum priority 🌸. TRILL Data packets SHOULD be sent with appropriate MPLS Traffic Classes, typically mapped from the TRILL Data packet priority, so that TRILL Data packet Traffic Classes denote priorities lower than the ones used for TRILL IS-IS PDUs 🍓. Doing this cuts down the chance that other traffic messes with these important control PDUs and causes false loss of adjacency or other control problems 🙈.
Now the MTU stuff, which is a little more involved 🧠. If a pseudowire supports fragmentation and reassembly (a feature that has gotten little or no deployment), then there's no reason to do TRILL MTU testing on it, and the pseudowire won't limit the TRILL campus-wide MTU size (Sz) (see Section 4.3.1 of [RFC6325]) 🦋. If the pseudowire doesn't support fragmentation (the more common case), then the available TRILL IS-IS packet payload size over the pseudowire (taking into account MPLS encapsulation with a control word), or some lower value, MUST be used in helping to determine MTU size (Sz) (see Section 5 of [RFC7180]) 💖.
Last thing in this section: an intervening MPLS label switched router, or any similar packet switched network device, has no awareness of TRILL 😌. Those devices won't change the TRILL Header hop count 💅.
2.2. PPP PWE3 Transport of TRILL 🎀
For a PPP pseudowire (PW type = 0x0007), the two TRILL switch ports being connected are configured to form a pseudowire with PPP encapsulation [RFC4618] 🧚. Once the pseudowire is established and TRILL use is negotiated within PPP, the two TRILL switch ports look directly connected with a PPP link [RFC1661] [RFC6361] ✨.
If pseudowire interconnection of two TRILL switch ports is signaled [RFC4447], the initiating TRILL switch port MUST attempt the connection setup with pseudowire type PPP (0x0007) 🔥. That part's non-negotiable, bestie 😤.
TRILL over a PPP pseudowire keeps following what TRILL over PPP specifies in Section 3 of [RFC6361] 🌈.
Next up are the figures for what a TRILL Data packet and a TRILL IS-IS packet look like over this pseudowire in the MPLS case, assuming no TRILL Header extensions 👑:
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Control Word | 4 octets
+--------------------------------+
| PPP Header 0x005d | 2 octets
+--------------------------------+
| TRILL Header | 6 octets
+--------------------------------+
| Destination MAC Address | 6 octets
+--------------------------------+
| Source MAC Address | 6 octets
+--------------------------------+
| Data Label | 4 or 8 octets
+--------------------------------+
| Payload Body | variable
+--------------------------------+
Figure 1: TRILL Data Packet in Pseudowire"Data Label" is the VLAN Label or Fine-Grained Label [RFC7172] of the payload 🏷️💜.
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Control Word | 4 octets
+--------------------------------+
| PPP Header 0x405d | 2 octets
+--------------------------------+
| Common IS-IS Header | 8 octets
+--------------------------------+
| IS-IS PDU Type Specific Header | variable
+--------------------------------+
| IS-IS TLVs | variable
+--------------------------------+
Figure 2: TRILL IS-IS Packet in PseudowireThe PPP Header fields for TRILL Data and IS-IS packets shown above (0x005d and 0x405d, respectively) are specified in [RFC6361] 🫶💖.
3. Security Considerations 🔐✨
okay so bestie, security is where things get SERIOUS 😭 but it's also where I get to be extra. TRILL-level security stuff, like using authentication with TRILL IS-IS PDUs [RFC6325], is not affected by the link technology, like using pseudowire links the way this document describes. 💅 that's giving "separate lanes, no drama" energy.
Link security can be a total glow-up for TRILL campus security 🌸 Here's the vibe: TRILL gets carried over pseudowires as TRILL over PPP over pseudowires, and those pseudowires ride on MPLS or IP, and MPLS and IP sit on some lower-level link technology. So link security below the TRILL level for a pseudowire link could come from PPP security, pseudowire security, MPLS or IP security, or security of the link technology under MPLS or IP. Lots of options, iykyk 🦋
PPP TRILL security is discussed in [RFC6361]. For the security stuff that shows up when you carry PPP TRILL links over pseudowires, check [RFC3985], which covers the risks of sending protocols that used to assume a point-to-point link over a pseudowire built on a packet switched network (PSN). Now here's the tea 🍵: the PPP layer in TRILL transport by pseudowire is kinda vestigial, ngl. It's mainly a convenient way to reuse existing PPP code points so you can identify TRILL Data packets and TRILL IS-IS packets. Also, existing PPP security standards are arguably questionable by current security criteria 💀 So it is NOT RECOMMENDED to use PPP security when transporting TRILL by pseudowire as specified in this document. Not me saying "use it anyway" 🙈
It is RECOMMENDED that link security be provided at the layers supporting the pseudowires carrying TRILL, that is, at the MPLS or IP layer or the link layer carrying MPLS or IP. Main character energy for your network 👑
For applications with sensitive data, end-to-end security should always be considered in addition to link security, so you get security in depth 🫶 In this context, that end-to-end security should be between the end stations involved, so it protects the entire path to, through, and from the TRILL campus. Literally the full journey, no gaps 🧚
For general TRILL protocol security considerations, see [RFC6325] 💖
Appendix A. Use of Other Pseudowire Types 🦋
This informational appendix briefly talks about using pseudowire types other than PPP to transport TRILL 🌈
The authors checked out Ethernet pseudowires [RFC4448] and found they would work without any changes 💅 However, that would add an extra 12 or 16 bytes per packet inside the payload sent over the pseudowire, for a TRILL Data packet (Figure 3) and a TRILL IS-IS packet (Figure 4) over such an Ethernet pseudowire in the MPLS case, assuming no TRILL Header extensions (compare with Figures 1 and 2). Okay, that's a lot of bytes bestie 😭
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Optional Control Word | 4 octets
+--------------------------------+
| TRILL Hop Dest. MAC Address | 6 octets
+--------------------------------+
| TRILL Hop Source MAC Address | 6 octets
+--------------------------------+
|Optional VLAN and/or other tags | variable
+--------------------------------+
| TRILL Ethertype (0x22f3) | 2 octets
+--------------------------------+
| TRILL Header | 6 octets
+--------------------------------+
| Destination MAC Address | 6 octets
+--------------------------------+
| Source MAC Address | 6 octets
+--------------------------------+
| Data Label | 4 or 8 octets
+--------------------------------+
| Payload Body | variable
+--------------------------------+
Figure 3: TRILL Data Packet in Ethernet Pseudowire"Data Label" is the VLAN Label or Fine-Grained Label [RFC7172] of the payload 🎀
+--------------------------------+
| Server MPLS Tunnel Label(s) | n*4 octets (4 octets per label)
+--------------------------------+
| PW Label | 4 octets
+--------------------------------+
| Optional Control Word | 4 octets
+--------------------------------+
| TRILL Hop Dest. MAC Address | 6 octets
+--------------------------------+
| TRILL Hop Source MAC Address | 6 octets
+--------------------------------+
|Optional VLAN and/or other tags | variable
+--------------------------------+
| Layer 2 IS-IS Ethertype 0x22f4 | 2 octets
+--------------------------------+
| Common IS-IS Header | 8 octets
+--------------------------------+
| IS-IS PDU Type Specific Header | variable
+--------------------------------+
| IS-IS TLVs | variable
+--------------------------------+
Figure 4: TRILL IS-IS Packet in Ethernet PseudowireIt would also be possible to make a brand new pseudowire type just for TRILL traffic 🧚 but the authors feel any efficiency gain over PPP pseudowires would be too small to be worth the complexity of adding that spec. Plus, using PPP pseudowire encoding means any traffic dissector that understands TRILL PPP encoding [RFC6361] and PPP pseudowires [RFC4618] will automatically be able to recursively decode TRILL carried over a pseudowire. Dissectors doing the work for us, no notes 💜
Acknowledgements 🫶
Thanks SO much to the people who gave valuable comments, listed in alphabetic order 💖
- Stewart Bryant, Stephen Farrell, Brian Haberman, Christer Holmberg, Joel Jaeggli, Barry Leiba, Erik Nordmark, Yaron Sheffer, and Yaakov (J) Stein.
Normative References 📚
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis,
"Encapsulation Methods for Transport of PPP/High-Level
Data Link Control (HDLC) over MPLS Networks", RFC 4618,
September 2006.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, "Routing Bridges (RBridges): Base Protocol
Specification", RFC 6325, July 2011.
[RFC6361] Carlson, J. and D. Eastlake 3rd, "PPP Transparent
Interconnection of Lots of Links (TRILL) Protocol Control
Protocol", RFC 6361, August 2011.
[RFC7172] Eastlake 3rd, D., Zhang, M., Agarwal, P., Perlman, R., and
D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, May 2014.
[RFC7180] Eastlake 3rd, D., Zhang, M., Ghanwani, A., Manral, V., and
A. Banerjee, "Transparent Interconnection of Lots of Links
(TRILL): Clarifications, Corrections, and Updates",
RFC 7180, May 2014.Informative References 🧠
[IS-IS] ISO/IEC 10589:2002, Second Edition, "Information
technology -- Telecommunications and information exchange
between systems -- Intermediate System to Intermediate
System intra-domain routeing information exchange protocol
for use in conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", 2002.
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, March 2005.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC7177] Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H., and
V. Manral, "Transparent Interconnection of Lots of Links
(TRILL): Adjacency", RFC 7177, May 2014.Authors' Addresses 💌
Lucy Yong
Huawei Technologies
5340 Legacy Drive
Plano, TX 75024
USA
Phone: +1-469-227-5837
EMail: lucy.yong@huawei.com
Donald E. Eastlake 3rd
Huawei Technologies
155 Beaver Street
Milford, MA 01757
USA
Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-330-4517
EMail: sam.aldrin@huawei.com
Jon Hudson
Brocade
130 Holger Way
San Jose, CA 95134
USA
Phone: +1-408-333-4062
EMail: jon.hudson@gmail.com📦 where this page comes from
- ietf: rfc7173 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms