idnits 2.17.1 draft-perlman-trill-rbridge-data-encoding-03.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 (Using the creation date from RFC6325, updated by this document, for RFC5378 checks: 2006-05-11) -- 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 (January 7, 2013) is 4125 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' -- Obsolete informational reference (is this intentional?): RFC 6327 (Obsoleted by RFC 7177) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT Intel Labs 3 Updates: 6325 Donald Eastlake 4 Intended status: Proposed Standard Yizhou Li 5 Huawei 6 Anoop Ghanwani 7 Dell 8 Expires: July 6, 2013 January 7, 2013 10 RBridges: TRILL Link Data Optimizations 11 13 Abstract 15 TRILL (TRansparent Interconnection of Lots of Links) Data frames can 16 be encoded so as to make more efficient use of communications links 17 under certain circumstances. This document specifies two such 18 optional optimizations. One, called Compact Format, improves the 19 compactness of encoding where a TRILL link is a point-to-point 20 Ethernet link. The other, called Specific Addressing, optionally 21 decreases the burden on multi-access TRILL links for multi- 22 destination TRILL Data frames. This document updates RFC 6325. 24 Status of This Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the TRILL working group mailing list . 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 1.1 Structure of This Document.............................3 51 1.2 Terminology Used in This Document......................4 53 2. The General TRILL Frame Format..........................5 54 2.1 The General TRILL Frame Format.........................5 55 2.2 Ethernet Link TRILL Data Frame General Encapsulation...6 57 3. Compact Format for Point-to-Point Ethernet Links........8 58 3.1 Conditions for Using Compact Format....................8 59 3.2 RBridge Originated and Terminated Native Frames.......10 60 3.3 Compact TRILL Data Reception and Transmission.........10 61 3.3.1 Compact TRILL Data Frame Reception..................10 62 3.3.2 Compact TRILL Data Frame Transmission...............12 63 3.4 Announcing Support for Compact Format.................12 65 4. Specific Addressing....................................13 66 4.1 Current Multi-Destination Addressing..................13 67 4.2 Specific Addressing Specification.....................13 68 4.3 Announcing Support for Specific Addressing............13 70 5. Interaction Between The Optimizations..................15 71 6. IANA Considerations....................................16 73 7. Security Considerations................................17 74 7.1 Compact Format Security Considerations................17 75 7.2 Specific Addressing Security Considerations...........17 76 7.3 Results of Frame Misinterpretation....................17 78 8. References.............................................19 79 8.1 Normative References..................................19 80 8.2 Informative References................................19 82 Authors' Addresses........................................21 84 1. Introduction 86 TRILL switches (also called RBridges (Routing Bridges)) are devices 87 that support the IETF TRILL (TRansparent Interconnection of Lots of 88 Links) protocol [RFC6325] [RFC6327] [ClearCorrect]. They provide 89 transparent forwarding of frames in multi-hop networks with arbitrary 90 topology and link technology using least cost paths for unicast 91 traffic and support VLANs (Virtual Local Area Networks) and the 92 multipathing of both unicast and multi-destination traffic. They 93 accomplish this by use of a hop count and IS-IS (Intermediate System 94 to Intermediate System) link state routing [IS-IS] [RFC1195] 95 [RFC6326bis]. 97 A link between two TRILL switches in a TRILL campus can be any of a 98 variety of technologies, ranging from a complex bridged LAN to PPP 99 [RFC6361]. In the general case under the base TRILL protocol 100 [RFC6325], a TRILL Data frame consists of an inner payload formatted 101 as an Ethernet frame, preceded by a TRILL Header, and then 102 encapsulated by a link envelope as appropriate for the link 103 technology. 105 1.1 Structure of This Document 107 Section 2 discusses General Format TRILL Data frames without the 108 enhancements specified in this document. 110 In the case where the link is a point-to-point Ethernet link, an 111 optional Compact Format is possible for TRILL Data frames that saves 112 16 bytes. Section 3 specifies that format, its processing, and the 113 conditions for its safe use. 115 In the case where a multi-destination TRILL Data frame is being 116 forwarded over a multi-access link with multiple ports connected but 117 there is only one (or perhaps a few) next hop TRILL switches of 118 interest, optional Specific Addressing allows the TRILL Data frame to 119 be link unicast. This can substantially reduce the burden that frame 120 represents if, for example, the link is a complex bridged LAN through 121 which the frame might otherwise be flooded. Section 4 specifies the 122 Specific Addressing enhancement and the conditions for its safe use. 124 Section 5 discusses potential interaction between these two 125 enhancements. The remaining Sections after Section 5 provide IANA and 126 Security Considerations, References, and the like. 128 This document updates [RFC6325]. 130 1.2 Terminology Used in This Document 132 The terminology and acronyms defined in [RFC6325] are used herein 133 with the same meaning. In particular, the terms "campus", "native 134 frame", "link", etc., are as defined [RFC6325]. 136 "Point-to-point", as used herein, means a link which appears to be an 137 isolated channel between exactly two TRILL switch ports. Such a link 138 may not include customer bridges but may include hubs/repeaters, Two 139 Port MAC Relays, Provider Bridges, Provider Back Bone Bridges 140 [802.1Q], or other technology, provided that technology is configured 141 to provide a transparent point-to-point path between the end point 142 RBridge ports. 144 References herein to "VLAN Tag" or the like are to customer VLANs (C- 145 Tags, Ethertype 0x8100). Use of S-Tags, also known as Service Tags, 146 or stacked VLAN or other tags is beyond the scope of this document 147 but is an obvious extension. 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. The General TRILL Frame Format 155 The subsections below provide a description of the general format of 156 TRILL Data frames. It then narrows in to describe the format of TRILL 157 Data frames on Ethernet links. 159 2.1 The General TRILL Frame Format 161 The general "on-the-wire" form of TRILL frames is illustrated below. 163 The Link Headers and Trailers in the formats below depend on the 164 specific link technology. The Link Header contains one or more fields 165 that distinguish TRILL Data from TRILL IS-IS. For example, over 166 Ethernet, the TRILL Data Link Header ends with the TRILL Ethertype 167 while the TRILL IS-IS frame Link Header ends with the L2-IS-IS 168 Ethertype; on the other hand, over PPP, there are no Ethertypes but 169 PPP protocol codes perform that function [RFC6361]. 171 A TRILL Data frame in transit between two neighboring RBridges is as 172 shown below: 174 +---------------+----------+----------------+---------------+ 175 | TRILL Data | TRILL | Payload | TRILL Data | 176 | Link Header | Header | Native Frame | Link Trailer | 177 +---------------+----------+----------------+---------------+ 179 Figure 1. Format of TRILL Data Frames 181 In the above diagram, the Payload Native Frame is in a restricted 182 Ethernet frame format with a VLAN tag but with no trailing Frame 183 Check Sequence (FCS). The payload frame format is shown below, 184 assuming the payload starts with an Ethertype (it might alternatively 185 be LLC [802-2001] encoded or some other format): 187 +-----------+------------+------+-----------+------------ 188 | MAC Dest. | MAC Source | VLAN | Content | Content ... 189 | Address | Address | Tag | Ethertype | ... 190 +-----------+------------+------+-----------+------------ 192 Figure 2. Format of the Payload Native Frame 194 The encapsulated payload has the following fields in sequence: 196 o A 6-byte destination MAC address (Inner.MacDA) 198 o A 6-byte source MAC address (Inner.MacSA) 200 o An Inner.VLAN tag giving the VLAN ID, Priority, and DEI (Drop 201 Eligibility Indicator) [ClearCorrect] of the payload (use of an S- 202 tag or stacked tags is beyond the scope of this document but is an 203 obvious extension) 205 o The payload frame's content (which usually starts with an 206 Ethertype, such as the Ethertype for IPv4 or IPv6) 208 TRILL IS-IS frames are also sent between neighboring RBridges and 209 must be distinguished from TRILL Data frames. TRILL IS-IS frames are 210 formatted as follows and cannot use the Compact Format specified 211 herein: 213 +--------------+---------------+--------------+ 214 | TRILL IS-IS | TRILL IS-IS | TRILL IS-IS | 215 | Link Header | Payload | Link Trailer | 216 +--------------+---------------+--------------+ 218 Figure 3. TRILL IS-IS Frame 220 2.2 Ethernet Link TRILL Data Frame General Encapsulation 222 If the link between neighbor RBridges is Ethernet, then the general 223 TRILL Data frame format has the following link encapsulation: 225 Link Header: a 6-byte outer MAC destination address (Outer.MacDA) 226 followed by a 6-byte outer MAC source address (Outer.MacSA) 227 followed by an optional 4-byte outer VLAN tag Ethertype and 228 value (Outer.VLAN), and finally the 2-byte TRILL Ethertype 229 (0x22F3). Additional tags could be included after the outer MAC 230 addresses and before the TRILL Ethertype based on Layer 2 231 Ethernet functions such a MACSEC [802.1AE]. 233 Under the TRILL standard before this document, the Outer.MacDA 234 was required to be the unicast MAC address of the destination 235 RBridge port if the TRILL Data frame was a unicast frame to a 236 known destination and was required to be the All-RBridges 237 multicast address if it was a multi-destination frame. 239 +-----------+------------+- - - - - +-----------+ 240 | MAC Dest. | MAC Source | VLAN Tag | TRILL | 241 | Address | Address | if Req. | Ethertype | 242 +-----------+------------+ - - - - -+-----------+ 244 Figure 4. TRILL Data Link Header on an Ethernet Link 246 Link Trailer: the 32-bit IEEE [802.3] Frame Check Sequence (FCS). 248 In the General Format for Ethernet links, the Outer.VLAN can be 249 omitted when it is not required by VLAN sensitive equipment in the 250 link. 252 3. Compact Format for Point-to-Point Ethernet Links 254 TRILL Data frames may optionally be sent using a Compact Format if 255 the link is a point-to-point Ethernet link, Compact Format can be 256 enabled by both RBridges on the link if other conditions met as 257 listed below. 16 bytes can be saved per frame as a result. 259 The Compact Format is simple: the Outer.MacDA, Outer.MacSA, and 260 Outer.VLAN are replaced by the Inner.MacDA, Inner.MacSA, and 261 Inner.VLAN and the Inner fields are deleted. This saves 6 + 6 + 4 or 262 16 bytes. To avoid confusion, Compact Format MUST NOT be used if the 263 Inner.MacDA is a multi-cast address assigned to TRILL 264 (01-80-C2-00-00-40 through 01-80-C2-00-00-4F). 266 Compact Format is not applicable to TRILL IS-IS frames because there 267 is no inner Ethernet header. (And, of course, Compact Format is not 268 applicable to native frames or Layer 2 control frames since those 269 frames are not TRILL frames.) 271 +---------------------+--------+-----------+---------+---------+ 272 | Ethernet Header | TRILL | Content | Content | Link | 273 | Header from Payload | Header | Ethertype | ... | Trailer | 274 +---------------------+--------+-----------+---------+---------+ 276 Figure 5. Compact Format TRILL Data Frame 278 Compact Format is generally intended for use on physical point-to- 279 point Ethernet links between RBridges, a common arrangement in many 280 LANs. However, if there are any transparent provider bridging devices 281 in the point-to-point link, such as Provider Bridges or Provider 282 Backbone Bridges, then the use of the Compact Format will increase 283 the MAC address learning table stress on such Provider Bridges or 284 Provider Edge Back Bone bridges. 286 3.1 Conditions for Using Compact Format 288 Use of Compact Format is a hop-by-hop decision. In successive RBridge 289 to RBridge hops, a TRILL Data frame might be sent alternately in 290 Compact Format and General Format. 292 There are a number of conditions for using Compact Format TRILL Data 293 frames. Most of these boil down to maximizing the assurance that the 294 RBridge-to-RBridge Ethernet link over which the Compact Format TRILL 295 Data frame is to be sent is really point-to-point. Only the General 296 Format for TRILL Data frames is safe to use on an RBridge Ethernet 297 port that is to a multi-access link even if the ports between which 298 it is being sent have been configured as point-to-point ports. The 299 following conditions apply. (See also the frame reception process 300 variations described in Section 3.3.1.) 302 o The RBridge port over which Compact Format TRILL Data frames are 303 to be sent MUST be configured as a point-to-point Ethernet port 304 (see Section 4.9.1 of [RFC6325]). 306 o The RBridge port through which the Compact Format TRILL Data frame 307 is being transmitted MUST be configured to send VLAN tagged 308 frames. Otherwise the VLAN of the payload may be lost. 310 o The RBridge port at the other end of the point-to-point link MUST 311 be announcing that it supports the Compact Format. See Section 312 3.4. 314 o Receipt of a native frame indicates that the link is multi-access 315 and has end stations on it. These are frames that are not Layer 2 316 control frames (see Section 1.4 of [RFC6325]) and have neither an 317 Outer.MacDA in the block assigned to TRILL nor an outer payload 318 EtherType assigned to/for TRILL (currently the TRILL and L2-IS-IS 319 EtherTypes). On receipt of such a frame, the port MUST stop using 320 Compact Format TRILL Data frames for at least ten seconds, unless 321 it is reset by management or rebooted before that. 323 o Receipt of a TRILL IS-IS Hello frame, other than a point-to-point 324 Hello from the RBridge believed to be at the other end of the 325 link, indicates that the link really isn't point-to-point or that 326 the RBridge at the other end of that link is mis-behaving. In 327 either case, the RBridge receiving such an unexpected Hello MUST 328 stop using Compact Format TRILL Data frames on that port for at 329 least twice the holding time in the unexpected Hello but not less 330 than ten seconds, unless it is reset by management or rebooted 331 before that. This is a change to [RFC6325] which states that an 332 RBridge port configured as point-to-point ignores TRILL Hellos. 334 o RBridge Ethernet ports are required to monitor ports for BPDUs 335 received (Section 4.9.3 [RFC6325]). On receipt of a customer 336 bridging BPDU at an RBridge port, the RBridge MUST stop using 337 Compact Format on that port and revert to sending General Format 338 TRILL Data frames for at least four times the Bridge Hello Time in 339 the BPDU, but not less than ten seconds, unless the port or 340 RBridge is reset by management or rebooted before that. 342 o It is RECOMMENDED that RBridge ports intending to use Compact 343 Format also use the Link Layer Discovery Protocol (LLDP) [802.1AB] 344 to provide additional assurance that the link is actually point- 345 to-point. For this use, LLDP should be run to the Nearest Customer 346 Bridge MAC address (01-80-C2-00-00-00). Receipt by an RBridge port 347 supporting LLDP of an LLDP message indicating the presence on the 348 link of a MAC Bridge, Layer 3 Router, or End Station indicates 349 that the link is not point-to-point and the RBridge MUST stop 350 using Compact Format on the port for at least twice the TTL in the 351 received LLDP frame but not less than ten second, unless the port 352 or RBridge is reset by management or rebooted before that. 354 3.2 RBridge Originated and Terminated Native Frames 356 There can be native frames originated by or intended for consumption 357 by an RBridge. Examples include SNMP over IP frames or RBridge 358 Channel frames [RFCchannel]. In many cases, such internal sinks and 359 sources of native frames are treated as a virtual end-station 360 internally attached to the RBridge. Such frames are converted to 361 TRILL Data frames before being transmitted outside the originating 362 RBridge. 364 Because of the way that Compact Format TRILL Data frames are 365 recognized, particularly the change in [RFC6325], Section 4.6.2, 366 Point 3, made by Section 3.3.1 of this document, an RBridge MUST use 367 a MAC address different from the address of any of its ports as the 368 Inner.MacSA of frames it locally originates and as the Inner.MacDA it 369 expects to see in unicast TRILL Data frames that it receives and 370 decapsulates for locally processing. 372 3.3 Compact TRILL Data Reception and Transmission 374 If an RBridge's Ethernet port has Compact Format enabled, frame 375 reception and transmission are modified as described below. 377 Section 4.6 of the TRILL base protocol standard [RFC6325] provides a 378 specification of the processing of all possible types of received 379 frames. There is no change in the definition of TRILL frames as 380 specified in [RFC6325] Section 1.4, that is, TRILL frames are any 381 frame starting with the TRILL or L2-IS-IS Ethertype or that has an 382 Outer.MacDA that is any of the block of 16 multicast addresses 383 assigned to TRILL ([RFC6325] Section 7.2). 385 3.3.1 Compact TRILL Data Frame Reception 387 Section 4.6.2 of [RFC6325] specifies the processing of received TRILL 388 frames. A complete replacement for Section 4.6.2 of [RFC6325] that 389 supports Compact Format and incorporates the correction in Section 390 5.1.2 of [ClearCorrect] is provided in the quoted text below. 392 Even when Compact Format is enabled, the sender is not required to 393 compact all or any TRILL Data frames and a receiver MUST be prepared 394 for an arbitrary mix of Compact Format and General Format TRILL Data 395 frames arriving on a point-to-point link. 397 NOTE: All of the Section references in the quoted text below are 398 references to Sections in [RFC6325]. 400 "A TRILL frame either has the TRILL or L2-IS-IS Ethertype or has a 401 multicast Outer.MacDA allocated to TRILL (see Section 7.2). The 402 following tests are performed sequentially, and the first that 403 matches controls the handling of the frame:" 405 "By default a frame is classified as General Format." 407 "1. If the Ethertype is L2-IS-IS and the Outer.MacDA is either 408 All-IS-IS-RBridges or the unicast MAC address of the 409 receiving RBridge port, the frame is handled as described in 410 Section 4.6.2.1 on TRILL Control frames." 412 "2. If the Outer.MacDA is a multicast address allocated to TRILL 413 other than All-RBridges then the frame is discarded." 415 "3. If the Outer.MacDA is a unicast address other than the 416 address of the receiving Rbridge then (3a) if Compact Format 417 TRILL Data frames are disabled, the frame is discarded or 418 (3b) if Compact Format TRILL Data frames are enabled, the 419 frame is classified as compact." 421 "4. If the Ethertype is not TRILL, the frame is discarded." 423 "5. If the Version field in the TRILL Header is greater than 0, 424 the frame is discarded." 426 "6. If the hop count is 0, the frame is discarded." 428 "7. If the Outer.MacDA is multicast and the M bit is zero the 429 frame is discarded. If the Outer.MacDA is unicast and M bit 430 is one processing continues if Specific Addressing is 431 enabled. If Specific Addressing is not enabled, the frame is 432 discarded." 434 "8. If the frame has been classified as Compact Format, skip the 435 rest of this rule and go to Rule 9. By default, an RBridge 436 MUST discard General Format TRILL Data frames from a 437 Outer.MacSA that is not an adjacency on the port where the 438 frame was received. RBridges MAY be configured per port to 439 accept such frames in cases where it is known that a non- 440 peering device (such as an end-station) is configured to 441 originate general TRILL encapsulated data frames that can be 442 safely accepted." 444 "9. If a frame has been classified as a Compact Format TRILL Data 445 frame but it was received untagged, that is, without an 446 Outer.VLAN, discard the frame." 448 "10. For all subsequent processing, including Rule 11, if the 449 frame has been classified as Compact Format, all references 450 to Inner.MacDA, Inner.MacSA, or Inner.VLAN are to be 451 understood to actually refer to the Outer.MacDA, Outer.MacSA, 452 and Outer.VLAN as the frame was received." 454 "11. The Inner.MacDA is then tested. If it is the All-Egress- 455 Rbridges (also known as All-ESADI-RBridges) multicast address 456 and RBn implements the ESADI protocol, processing proceeds as 457 in Section 4.6.2.2 for TRILL ESADI frames. If it is any other 458 address or RBn does not implement ESADI, processing proceeds 459 as in Section 4.6.2.3 for TRILL Data frames." 461 3.3.2 Compact TRILL Data Frame Transmission 463 When a TRILL Data frame is being transmitted out an RBridge port, if 464 the conditions listed in Section 3 above are met, the frame MAY be 465 sent in Compact Format. 467 3.4 Announcing Support for Compact Format 469 The Compact Format option is a hop-by-hop optional Ethernet link 470 TRILL frame format and it is possible that an RBridge would support 471 it on some ports and not others depending, for example, on port 472 hardware. Therefore, if Compact Format is enabled at a port, this is 473 indicated in every Hello (Section 6) it sends out that port. 475 4. Specific Addressing 477 Specific addressing optionally enables more efficient use of some 478 types of multi-access links. 480 4.1 Current Multi-Destination Addressing 482 When multiple RBridges are connected to an Ethernet link, the base 483 TRILL protocol standard [RFC6325] requires that multi-destination 484 TRILL Data frames be sent on the Ethernet link addressed to the All- 485 RBridges multicast address. 487 If the link is a multi-access link, such as a large bridged LAN, use 488 of a multicast address may impose a significant burden, causing the 489 frame to be flooded in the bridged LAN. In addition, all or many 490 stations attached to the bridged LAN may received the frame using up 491 some of their input bandwidth. Those TRILL switches that receive the 492 frame but are not the next hop on the frame's distribution tree will 493 discard the frame due to the Reverse Path Forwarding Check. 495 4.2 Specific Addressing Specification 497 Multi-destination TRILL Data frames are sent on the distribution tree 498 identified in the TRILL Header subject to optional pruning. The 499 transmitting RBridge thus knows which next hop RBridge or RBridges on 500 the link it needs to get the frame to. 502 If the next hop RBridges on the multi-access link and the 503 transmitting RBridge all have Specific Addressing enabled, then the 504 frame MAY be link unicast to the next hop RBridge or RBridges. 506 Use of Specific Addressing is a hop-by-hop optional decision. 507 Successive TRILL Data frames received by an RBridge, even from the 508 same sending RBridge on the same distribution tree, may be 509 specifically (unicast) or multicast addressed. (The same frame is 510 never sent both ways.) In successive RBridge to RBridge hops, a 511 multi-destination TRILL Data frame might be sent alternately in 512 specifically addressed and multicast addressed form. 514 4.3 Announcing Support for Specific Addressing 516 The Specific Addressing option is a hop-by-hop optional format. It is 517 possible that an RBridge would support it on some ports and not 518 others. Therefore enablement of this option is indicated in every 519 TRILL Hello (see Section 6) sent on the port. 521 5. Interaction Between The Optimizations 523 Compact Format can only be used for TRILL Data frames on Ethernet 524 links that are point-to-point. Compact Format works under the 525 conditions specified above regardless of whether the frame is TRILL 526 unicast (M=0) or TRILL multi-destination (M=1). It sets the 527 Outer.MacDA, Outer.MacSA, and Outer.VLAN to the corresponding Inner 528 fields and removes the Inner fields. 530 Specific Addressing is only beneficial for frames that are TRILL 531 multi-destination Data frames on multi-access links. Specific 532 Addressing causes the frame to be link unicast by setting the 533 Outer.MacDA to the unicast address of a next hop RBridge. 535 Both optimizations change the Outer.MacDA from its value in the base 536 TRILL protocol and thus they conflict. Specific Addressing MUST NOT 537 be used on point-to-point Ethernet links, which avoids any conflict. 539 6. IANA Considerations 541 IANA is requested to allocate two capability bits in the TRILL-PORT- 542 VER sub-TLV [RFC6326bis] as follows: 544 Bit Description Reference 545 ====== ============================== ================= 546 tbd1 Compact Ethernet enabled. (This document) 547 tbd2 Specific addressing enabled. (This document) 549 7. Security Considerations 551 For general TRILL protocol security considerations, see [RFC6325]. 552 See other security considerations below. 554 7.1 Compact Format Security Considerations 556 An RBridge conformant to the TRILL standard that has Compact Format 557 TRILL Data not implemented or not enabled on a port will, as part of 558 its normal procedures, discard any Compact Format TRILL Data frame it 559 receives on that port because the EtherType of the frame would be 560 TRILL but (1) if the Compact Format resulted in a unicast 561 Outer.MacDA, it would not be the address of the receiving RBridge 562 port, and (2) if the Compact Format resulted in a multicast or 563 broadcast Outer.MacDA, it would not be the All-RBridges multicast 564 address. If the RBridge port failed to discard the frame and 565 erroneously handled it as being in General Format, bad things will 566 usually happen as described in Section 7.3. 568 With a General Format TRILL Data frame, the VLAN of the data is 569 somewhat protected in the Inner.VLAN field. With Compact Format, it 570 is put in the more exposed Outer.VLAN field. If it is stripped, 571 perhaps by an intervening bridge, and the frame arrives untagged, the 572 rules in this document require that it be discarded to avoid changing 573 the VLAN labeling of the frame to the default of the receiving 574 RBridge port. 576 7.2 Specific Addressing Security Considerations 578 It is important not to apply both Compact Format optimization and 579 Specific Addressing optimization to the same frame or else the frame 580 may be misinterpreted as described in Section 7.3. For this reasons, 581 use of Specific Addressing on point-to-point links, where it would 582 not provide an advantage anyway, is prohibited. 584 7.3 Results of Frame Misinterpretation 586 For frames that are misinterpreted due to circumstances described in 587 Sections 7.1 and 7.2, the first six bytes of the native frame content 588 will be treated as the Inner.MacDA, the next six bytes of that oontnt 589 as the Inner.MacSA, and the next four bytes as the Inner.VLAN. If the 590 Ethertype or the Inner.VLAN is not checked or some of the payload 591 data accidentally has the value of a VLAN tag Ethertype, the payload 592 may be delivered in the wrong VLAN violating security policy. For 593 this reason, the provisions of Sections 3 of this document should be 594 scrupulously enforced. 596 8. References 598 Normative and informative references for this document are given 599 below. 601 8.1 Normative References 603 [802.1AB] - IEEE, "IEEE Standard for Local and metropolitan area 604 networks / Station and Media Access Control Connectivity 605 Discovery", IEEE Std 802.1AB-2009, 17 September 2009. 607 [802.1Q] - IEEE, "IEEE Standard for Local and metropolitan area 608 networks / Virtual Bridged Local Area Networks", IEEE Std 609 802.1Q-2011, May 2011. 611 [IS-IS] - ISO/IEC 10589:2002, Second Edition, "Intermediate System to 612 Intermediate System Intra-Domain Routing Exchange Protocol for 613 use in Conjunction with the Protocol for Providing the 614 Connectionless-mode Network Service (ISO 8473)", 2002. 616 [RFC1195] - Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 617 dual environments", RFC 1195, December 1990. 619 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 623 Ghanwani, "Routing Bridges (RBridges): Base Protocol 624 Specification", RFC 6325, July 2011. 626 [RFC6326bis] - Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., and 627 A. Ghanwani, "TRILL Use of IS-IS", draft-eastlake-isis- 628 rfc6326bis, work in progress. 630 [ClearCorrect] - draft-eastlake-trill-rbridge-clear-correct, work in 631 progress. 633 8.2 Informative References 635 [802-2001] - IEEE 802, "IEEE Standard for Local and Metropolitan Area 636 Networks / Overview and Architecture", 802-2001, 6 December 637 2001. 639 [802.1AE] - IEEE 802, "IEEE Standard for Local and metropolitan area 640 networks / Media Access Control (MAC) Security", 802.1AE-2006, 641 18 August 2006. 643 [802.3] - IEEE, "IEEE Standard for Information technology / 644 Telecommunications and information exchange between systems / 645 Local and metropolitan area networks / Specific requirements 646 Part 3: Carrier sense multiple access with collision detection 647 (CSMA/CD) access method and physical layer specifications", 648 IEEE Std 802.3-2008, 26 December 2008. 650 [RFC6327] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Dutt, D., 651 and V. Manral, "Routing Bridges (RBridges): Adjacency", RFC 652 6327, July 2011. 654 [RFC6361] - Carlson, J. and D. Eastlake 3rd, "PPP Transparent 655 Interconnection of Lots of Links (TRILL) Protocol Control 656 Protocol", RFC 6361, August 2011. 658 [RFCchannel] - Eastlake, D., V. Manral, L. Yizhou, S. Aldrin, D. 659 Ward, "RBridges: TRILL RBridge Channel Support", draft-ietf- 660 trill-rbridge-channel, work in progress. 662 Authors' Addresses 664 Radia Perlman 665 Intel Labs 666 2200 Mission College Blvd. 667 Santa Clara, CA 95054-1549, USA 669 Phone: +1-408-765-8080 670 Email: Radia@alum.mit.edu 672 Donald E. Eastlake 3rd 673 Huawei R&D USA 674 155 Beaver Street 675 Milford, MA 01757, USA 677 Phone: +1-508-333-2270 678 Email: d3e3e3@gmail.com 680 Yizhou Li 681 Huawei Technologies 682 101 Software Avenue, 683 Nanjing 210012, China 685 Phone: +86-25-56622310 686 Email: liyizhou@huawei.com 688 Anoop Ghanwani 689 Dell 690 350 Holger Way 691 San Jose, CA 95134 USA 693 Phone: +1-408-571-3500 694 Email: anoop@alumni.duke.edu 696 Copyright and IPR Provisions 698 Copyright (c) 2013 IETF Trust and the persons identified as the 699 document authors. All rights reserved. 701 This document is subject to BCP 78 and the IETF Trust's Legal 702 Provisions Relating to IETF Documents 703 (http://trustee.ietf.org/license-info) in effect on the date of 704 publication of this document. Please review these documents 705 carefully, as they describe your rights and restrictions with respect 706 to this document. Code Components extracted from this document must 707 include Simplified BSD License text as described in Section 4.e of 708 the Trust Legal Provisions and are provided without warranty as 709 described in the Simplified BSD License. The definitive version of 710 an IETF Document is that published by, or under the auspices of, the 711 IETF. Versions of IETF Documents that are published by third parties, 712 including those that are translated into other languages, should not 713 be considered to be definitive versions of IETF Documents. The 714 definitive version of these Legal Provisions is that published by, or 715 under the auspices of, the IETF. Versions of these Legal Provisions 716 that are published by third parties, including those that are 717 translated into other languages, should not be considered to be 718 definitive versions of these Legal Provisions. For the avoidance of 719 doubt, each Contributor to the IETF Standards Process licenses each 720 Contribution that he or she makes as part of the IETF Standards 721 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 722 language to the contrary, or terms, conditions or rights that differ 723 from or are inconsistent with the rights and licenses granted under 724 RFC 5378, shall have any effect and shall be null and void, whether 725 published or posted by such Contributor, or included with or in such 726 Contribution.