idnits 2.17.1 draft-ietf-trill-rbridge-oam-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 (March 12, 2012) is 4426 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) == Unused Reference: 'RFC6291' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'RBridgeMIB' is defined on line 1199, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-trill-rbridge-channel-05 == Outdated reference: A later version (-07) exists of draft-ietf-trill-rbridge-bfd-02 == Outdated reference: A later version (-10) exists of draft-ietf-trill-rbridge-mib-06 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6326 (Obsoleted by RFC 7176) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL Working Group D. Bond 3 Internet-Draft IBM 4 Intended status: Standards Track V. Manral 5 Expires: September 13, 2012 HP Networking 6 March 12, 2012 8 Routing Bridges (RBridges): Operations, Administration, and Maintenance 9 (OAM) Support 10 draft-ietf-trill-rbridge-oam-02 12 Abstract 14 Routing Bridges (RBridges) implement the TRansparent Interconnection 15 of Lots of Links (TRILL) protocol which provide a transparent least- 16 cost frame routing in multi-hop networks with arbitrary topologies, 17 while also inherently providing loop mitigation. As RBridges are 18 deployed in real-world situations, operators will need tools for 19 debugging problems that arise. This document specifies a set of 20 RBridge features for operations, administration, and maintenance 21 (OAM) purposes in RBridge campuses. The features specified in this 22 document include tools for traceroute, ping, and error reporting. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. TRILL OAM Message . . . . . . . . . . . . . . . . . . . . . . 6 62 4. RBridge Tools . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Application RBridge Tools . . . . . . . . . . . . . . . . 7 64 4.1.1. RBridge Ping . . . . . . . . . . . . . . . . . . . . . 8 65 4.1.2. Hop Count Traceroute . . . . . . . . . . . . . . . . . 9 66 4.1.2.1. Path Sharing . . . . . . . . . . . . . . . . . . . 10 67 4.1.2.2. Multi-Destination Targets . . . . . . . . . . . . 11 68 4.2. Error Reporting . . . . . . . . . . . . . . . . . . . . . 12 69 4.2.1. Hop Count Zero Error . . . . . . . . . . . . . . . . . 12 70 4.2.2. MTU Error . . . . . . . . . . . . . . . . . . . . . . 13 71 5. RBridge Channel Message Format . . . . . . . . . . . . . . . . 13 72 5.1. RBridge Channel Header and Sequence Number . . . . . . . . 13 73 6. OAM Protocol Field Values . . . . . . . . . . . . . . . . . . 14 74 6.1. Response Frame Field Values . . . . . . . . . . . . . . . 14 75 6.2. Self-Initiated Frame Field Values . . . . . . . . . . . . 16 76 7. OAM Protocol Formats . . . . . . . . . . . . . . . . . . . . . 17 77 7.1. Protocol Application Codes Formats . . . . . . . . . . . . 17 78 7.1.1. Echo Request . . . . . . . . . . . . . . . . . . . . . 17 79 7.1.2. Echo Reply . . . . . . . . . . . . . . . . . . . . . . 18 80 7.2. Error Notification Format . . . . . . . . . . . . . . . . 19 81 7.2.1. Error Specifiers . . . . . . . . . . . . . . . . . . . 20 82 8. Type, Length, Value (TLV) Encodings . . . . . . . . . . . . . 21 83 8.1. Next Hop Information . . . . . . . . . . . . . . . . . . . 23 84 8.2. Previous Hop Information . . . . . . . . . . . . . . . . . 24 85 8.3. Incoming Port ID . . . . . . . . . . . . . . . . . . . . . 24 86 8.4. Outgoing Port ID . . . . . . . . . . . . . . . . . . . . . 25 87 8.5. Outgoing Port MTU . . . . . . . . . . . . . . . . . . . . 25 88 8.6. IS-IS System ID . . . . . . . . . . . . . . . . . . . . . 26 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 92 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 93 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 94 12.2. Informative References . . . . . . . . . . . . . . . . . . 28 95 Appendix A. Implementation Considerations . . . . . . . . . . . . 29 96 A.1. Hop Count Traceroute Example . . . . . . . . . . . . . . . 29 97 A.2. Ping Example . . . . . . . . . . . . . . . . . . . . . . . 31 98 Appendix B. Revision History . . . . . . . . . . . . . . . . . . 32 99 B.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 32 100 B.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 33 102 1. Introduction 104 The IETF has standardized RBridges, devices that implement the TRILL 105 protocol, a solution for transparent least-cost frame routing in 106 multi-hop networks with arbitrary topologies, using a link-state 107 routing protocol technology and encapsulation with a hop-count 108 [RFC6325]. As RBridges are deployed, operators will require tools 109 for troubleshooting of operations issues in the network. TRILL uses 110 IS-IS for the control plane [IS-IS] [RFC6165] [RFC6326]. IS-IS has a 111 link-state database which contains the information of all links in 112 the TRILL domain and IS-IS has a routing table. This information can 113 be used for trouble shooting purposes. 115 There are a number of mechanisms to verify the control plane/data 116 plane information, however correctness of the control plane 117 information does not guarantee the data plane is working correctly. 118 This motivates the need for OAM tools that allow an operator to test 119 the data plane. Protocols such as IP, MPLS, and IEEE 802.1 have 120 features enabling an operator to exercise the data plane [RFC4443] 121 [RFC0792] [IEEE.802-1ag]. There is a need for a similar set of tools 122 in TRILL. Likewise, there is a need for error reporting capabilities 123 inside an RBridge campus. 125 Sometimes there may be a need for faster convergence than is provided 126 by the TRILL hello protocol. Such fault notification functionality 127 is not specified in this document. [BFD] provides this functionality 128 using BFD. 130 This document specifies a set of RBridge features for operations, 131 administration, and maintenance purposes in RBridge campuses along 132 with the procedures and frame formats for these features. The 133 features specified in this document include tools for traceroute, 134 ping, and error reporting. Section 3 of this document specifies the 135 general usage of a defined message format. Section 4 specifies some 136 additional applications of the message format. Section 5 specifies 137 the format and value of the messages on the wire. 139 1.1. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 2. Acronyms 147 o BPDU - Bridge PDU 148 o CHbH - Critical Hop-by-Hop 150 o CItE - Critical Ingress-to-Egress 152 o DA - Destination Address 154 o DR - Designated Router 156 o DRB - Designated RBridge 158 o ES - End Station 160 o ESa - End Station A 162 o ESb - End Station B 164 o ECMP - Equal-Cost Multi-Path 166 o ESADI - End Station Address Distribution Instance 168 o FCS - Frame Check Sequence 170 o ID - Identification 172 o IEEE - Institute of Electrical and Electronics Engineers 174 o IETF - Internet Engineering Task Force 176 o IP - Internet Protocol 178 o IS-IS - Intermediate System to Intermediate System 180 o MAC - Media Access Control 182 o MPLS - Multiprotocol Label Switching 184 o MTU - Maximum Transmission Unit 186 o OAM - Operations, Administration, and Maintenance 188 o P2P - Point-to-point 190 o PDU - Protocol Data Unit 192 o RBridge - Routing Bridge 194 o SA - Source Address 195 o SNMP - Simple Network Management Protocol 197 o TCP - Transmission Control Protocol 199 o TLV - Type, Length, Value 201 o TRILL - TRansparent Interconnection of Lots of Links 203 o UDP - User Datagram Protocol 205 o VLAN - Virtual Local Area Network 207 3. TRILL OAM Message 209 To facilitate message passing as needed by the OAM requirements, the 210 TRILL RBridge Channel facility [RBridgeChannel] is utilized. 212 There are two types of TRILL OAM messages defined in this document 213 carried within an RBridge Channel: application and error 214 notification. Frames with an error notification MUST NOT be 215 generated in response to frames that are an error notification. 216 Implementations SHOULD rate limit the origination of error 217 notifications. Whereas unknown unicast frames are sent as multi- 218 destination messages, sending unknown unicast frames with an error 219 can lead to an amplification attack. As such special care and rate 220 limiting are necessary for error notifications. 222 Error notification messages contain the error-causing frame or the 223 initial part thereof after its OAM message. The following are two 224 figures showing application and error notification message structure. 225 Section 5 goes into the details of these formats. 227 +----------------------------+ 228 | Outer Link Header | 229 +----------------------------+ 230 | TRILL Header | 231 +----------------------------+ 232 | Inner Ethernet Header | 233 +----------------------------+ 234 | RBridge Channel Header | 235 +----------------------------+ 236 | OAM Protocol Spec. Payload | 237 +----------------------------+ 239 Application Frame 240 Figure 1 242 +---------------------------------------+ 243 | Outer Link Header | 244 +---------------------------------------+ 245 | TRILL Header | 246 +---------------------------------------+ 247 | Inner Ethernet Header | 248 +---------------------------------------+ 249 | RBridge Channel Header | 250 +---------------------------------------+ 251 | OAM Protocol Specific Payload | 252 +---------------------------------------+ 253 | Offending Frame TRILL Header | 254 +---------------------------------------+ 255 | Offending Frame Inner Link Header | 256 +---------------------------------------+ 257 | Truncated Offending Frame Payload | 258 +---------------------------------------+ 260 Error Notification Frame 262 Figure 2 264 RBridge campuses do not, in general, guarantee lossless transport of 265 frames so a frame containing a TRILL OAM Message, possibly generated 266 in response to some other frame, might be lost. 268 4. RBridge Tools 270 This section specifies a number of RBridge OAM tools. For 271 classification purposes they are divided into two sections, 272 applications and error tools. Both of these tools use messages 273 called echo requests and echo replies. The format is described in 274 Section 5. An echo request is a message that says please respond. 275 The echo reply is that response. The exact usage is further defined 276 in this section. These messages also contain TLV fields which carry 277 additional information in regards to the message. The formats of 278 these TLVs are described in Section 8. 280 4.1. Application RBridge Tools 281 4.1.1. RBridge Ping 283 Ping is a tool for verifying RBridge connectivity. The ping- 284 originating RBridge transmits one or more TRILL data frames with a 285 TRILL OAM message. This message contains the code of an echo request 286 (See Section 7.1.1). The ingress RBridge MUST be the frame- 287 originating RBridge. The egress RBridge is the destination RBridge 288 to which connectivity will be checked. The M bit MUST be zero. 290 The purpose of the ping is to confirm connectivity of the data plane, 291 and options defined in future drafts MAY be included. The purpose of 292 allowing the addition of options is so that the frame mimics a data 293 frame that follows the same path through the data plane that a 'real' 294 data frame would. An RBridge Ping, however, uses the OAM Channel and 295 so depending on the ECMP hashing used by RBridges in the campus it 296 may not in fact share the same path as 'real' data going through the 297 network. The traceroute tool has a way to ensure the data follows 298 the same path as the data does and if an operator wishes to test that 299 path the data takes, the traceroute functionality ought to be used. 301 The echo request MAY have an arbitrary 28-bit unsigned integer 302 sequence number to assist in matching reply messages to the request. 303 In most circumstances, a single echo request is needed to complete 304 the ping but it might be desirable for a single RBridge to ping 305 multiple egress RBridges, or trace differing flows simultaneously. 306 Assigning differing sequence numbers to each frame aids in matching 307 which trace the reply belongs to. 309 The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress 310 Nickname SHOULD default to the values specified in Section 6.2. 312 RBridges implementing ping SHOULD issue a reply in response to this 313 request. See Section 11 for reasons that RBridges are allowed to 314 choose not to respond to a request. If an RBridge chooses to respond 315 to the request, the reply MUST consist of one TRILL data frame per 316 request with an OAM message containing the protocol code of an echo 317 reply. The echo reply MUST have the same sequence number as the 318 request being matched. 320 For the echo reply the ingress RBridge field MUST be the reply- 321 originating RBridge's nickname. The egress RBridge MUST be the 322 request-originating RBridge's nickname. The Inner.VLAN, Inner.MacSA, 323 and Inner.MacDA SHOULD default to the values specified in 324 Section 6.1. The M bit MUST be zero for a known unicast ping. 326 The reply-originating RBridge SHOULD include its 16-bit port ID from 327 the port on which the request was received in the incoming port field 328 of the reply. It SHOULD also include its 16-bit port ID from the 329 port on which the frame would be forwarded. A port ID of 0xFFFF 330 indicates the frame would not have been forwarded and that the frame 331 was consumed by the RBridge itself. 333 The reply frame need not follow the same path though the campus as 334 the request. The reply messages are not meant to test the data 335 plane. 337 End stations are not involved in this the ping process. RBridge 338 pings are from RBridge to RBridge. While the frames sent may emulate 339 data sent from ESa to ESb, the end stations are not, in fact, 340 involved. 342 The transmitting RBridge MUST wait for a reply frame until a time-out 343 occurs. At that time, the RBridge SHOULD assume the frame was lost, 344 and this SHOULD be indicated to the operator. The length of this 345 time-out is beyond the scope of this document. 347 4.1.2. Hop Count Traceroute 349 The ability to trace the path the data takes through the network is 350 an invaluable debugging tool. RBridge traceroute provides this 351 functionality through use of the TRILL OAM message (See Section 3). 352 In a hop-count traceroute, the originating RBridge starts by 353 transmitting one TRILL data frame with a TRILL OAM message. This 354 message contains a protocol code of an echo request (See 355 Section 7.1.1). The ingress RBridge MUST be the RBridge originating 356 the frame. 358 When a traceroute is initiated, it is either targeting a known 359 unicast target or a multi-destination target as specified by the 360 operator. If the hop-count traceroute is for a known unicast target, 361 the egress RBridge is the destination RBridge to which connectivity 362 will be checked and the M bit MUST be zero. Otherwise, if the hop- 363 count traceroute is for a multi-destination target, the egress 364 RBridge is the distribution tree nickname for the traceroute. Multi- 365 destination targets are handled the same as known unicast targets but 366 require a small amount of additional logic as specified in 367 Section 4.1.2.2. 369 The first echo request frame transmitted MUST have a hop-count of 370 zero. The RBridge will continue transmitting these echo requests, 371 incrementing the hop-count by one each time until a hop-count error 372 notification from the destination nickname as its ingress nickname is 373 received. If a transit RBridge decrements the hop-count by more than 374 one it MAY transmit multiple hop-count error notifications. 376 The purpose of the traceroute is to confirm connectivity of the data 377 plane, and therefore options defined in future drafts MAY be 378 included. The purpose of allowing the addition of options is so that 379 the frame mimics a data frame that follows the same path through the 380 data plane that a 'real' data frame would. The ability to share the 381 same path as 'real' data is further specified in Section 4.1.2.1. 383 The echo request MAY have an arbitrary 28-bit unsigned integer 384 sequence number to assist in matching reply messages to the request. 385 This is important for the hop-count traceroute since replies may 386 return to the ingress RBridge in a different order then their 387 matching requests were sent. 389 The Inner.VLAN, Inner.MacSA, Inner.MacDA, Inner.Priority, and Ingress 390 Nickname SHOULD default to the values specified in Section 6.2. 392 The replying RBridge SHOULD include its 16-bit port ID from the port 393 on which the hop-count error generating frame was received in the 394 Incoming Port ID TLV of the reply. It SHOULD also include its 16-bit 395 port ID from the port on which the frame would be forwarded if the 396 frame did not have a hop-count error in the Outgoing Port ID TLV. A 397 port ID of 0xFFFF indicates the frame would not have been forwarded 398 and would be consumed by the RBridge itself. Finally the reply 399 SHOULD include a 16-bit nickname and 48-bit system id of the next hop 400 RBridge the frame would have been sent to if there were no error in 401 the Next Hop Nickname TLV. If this RBridge is the egress RBridge 402 this TLV MUST NOT be included in the response. This is to facilitate 403 knowledge of a more precise path through the campus as seen in RFC 404 5837 [RFC5837]. 406 The advantage of this traceroute method is that the transit RBridges 407 do not have to do any special processing of the frames until a hop- 408 count error is detected, a condition they are required to detect by 409 the TRILL base protocol. The disadvantage is the request-orginating 410 RBridge needs to transmit as many frames as there are hops between 411 itself and the destination RBridge. 413 The end stations are not involved in this process. RBridge 414 traceroutes are from RBridge to RBridge. While the frames sent may 415 emulate data sent from ESa to ESb, the end stations are not, in fact, 416 involved. An Rbridge must keep the TRILL header contents the same 417 for ever frame sent in a hop count traceroute. 419 4.1.2.1. Path Sharing 421 In certain cases it could be important to send 'real' data over a 422 network as to test the path that 'real' data takes and to test the 423 fate that such real data would have. Simple sending an RBridge 424 channel message is insufficient because many RBridge implementations 425 will use various forms of ECMP hashing based on fields such as MAC 426 addresses, IP addresses, and/or TCP/UDP port numbers. To satisfy 427 this need for path sharing an RBridge originating a traceroute MAY 428 send a data packet instead of an echo request. The data packet will 429 look entirely like an encapsulated data frame, with whatever fields 430 the user specifies to ensure path sharing. The one exception is that 431 the hop count will be set as described previously: incremented as the 432 traceroute proceeds. Since these frames will not include a sequence 433 number, these data frames must be sent in lock step: waiting for a 434 timeout or an hop count error before sending the next incremented hop 435 count frame. Since this data frame looks like a real frame but is in 436 fact not real, when the egress RBridge is reached in the traceroute 437 the originating RBridge MUST NOT send trace frames with higher hop- 438 counts. RBridge ping does not have an equivalent path sharing 439 mechanism since it tests end to end connectivity rather than the 440 exact path taken. 442 4.1.2.2. Multi-Destination Targets 444 For multi-destination targets at each branch in the tree the tagged 445 frame will be replicated causing each RBridge in the tree, possibly 446 pruned by VLAN and/or IP multicast group, to send a response to the 447 echo request. If all RBridges in the possibly pruned distribution 448 tree support the echo request message, then the ingressing RBridge 449 will receive an error notification from each of them. These error 450 replies are staggered by distance from the generating RBridge. 451 Meaning the first set of responses come from the first request send 452 with hop count equal to zero and these repies will be from this 453 RBridges neighbors. The second set of responses will come from 454 RBridge two hops away and so forth. 456 The ingressing RBridge can compile all of these notifications, using 457 the parent pointers located in the previous hop information TLV, into 458 an output of the tree the traffic traversed. A traceroute 459 application SHOULD report any errors received, such as an invalid 460 distribution tree nickname, caused by the hop-count traceroute 461 frames. RBridges receiving a multicast destination echo request MUST 462 NOT transmit an echo reply if the multi-destination bit is set. Echo 463 requests that are not used with the hop-count traceroute come from 464 the ping tool, and ping messages are not valid as multi-destination 465 traffic. In a hop count traceroute, devices will already be 466 transmitting a hop-count error notification and so there is no reason 467 to transmit a double set of replies. A multi-destination hop-count 468 traceroute stops when the transmitted hop count reaches the maximum, 469 0x3F. One cannot use the diemater of the network to limit when this 470 traceroute stops because some RBridges may decrement the hop count by 471 more than one. 473 In multi-destination request frames, the Previous Information TLV 474 MUST be set to the nickname and system id of the RBridge the frame 475 was received from. This is the previous hop RBridge. The Next Hop 476 Information TLV is not used in multi-destination traceroute frames. 478 4.2. Error Reporting 480 Errors can occur in received TRILL data frames. For this purpose, 481 the error notification format is specified. These are generated due 482 to various events as specified subsequently. When a TRILL data frame 483 is received with an error, an error notification frame SHOULD be 484 generated. See Section 11 for reasons some RBridges are allowed to 485 choose not to respond to a request. The generated reply MUST contain 486 the error notification. The sub-code MUST contain a code specifying 487 the error encountered. The valid sub-code values are specified in 488 Section 7.2.1. Two of these sub-codes provide for TLVs with 489 additional information. The error notification also contains a 3 bit 490 error type field which describes the error. 492 This frame has a TRILL header and it contains, as its payload, the 493 frame received with the error. If the size of the received frame 494 would cause the generated frame to exceed 1470 bytes, the frame MUST 495 be truncated to the 1470 bytes. The payload MUST include the TRILL 496 header of the received frame and MUST NOT include the link-layer 497 header. The generated reply MUST contain the error notification 498 message specific to the error. 500 When the original ingress RBridge receives the error frame, at a 501 minimum, the RBridge SHOULD update a counter specifying the number of 502 error frames received for the causing error. The encapsulated frame 503 MUST NOT be egressed. 505 The two sub-codes that provide for TLVs with additional information 506 are described below. All other sub-codes specified in this document 507 do not normally contain TLVs. 509 4.2.1. Hop Count Zero Error 511 When a TRILL data frame is received with a hop-count of zero, an 512 error notification frame SHOULD be generated unless rate limiting or 513 some particular difficulty, as described below, stops the sending of 514 such an error notification. The generated reply MUST contain the 515 hop-count zero error sub-code. If the received frame has the echo 516 request message, the hop-count zero error notification MUST have a 517 sequence number matching the echo request. Otherwise, the sequence 518 number MUST be set to zero. The Incoming Port ID TLV SHOULD be 519 included with the port ID the received frame arrived on. The 520 Outgoing Port ID TLV SHOULD be included with the port ID of the port 521 the received frame would have been forwarded onto if the hop-count 522 was not zero. Finally, the error notification SHOULD include a 16- 523 bit nickname and 48-bit system id of the next hop RBridge the frame 524 would have been sent to in the Next Hop Information TLV. If the 525 request is a multi-destination frame, the previous hop information 526 SHOULD be included instead with it set to the nickname and system id 527 of the RBridge the frame was received from. This is the previous hop 528 RBridge. If the RBridge transmitting the reply is the egress 529 RBridge, this TLV MUST NOT be included in the frame. 531 4.2.2. MTU Error 533 When a TRILL data frame is received with a payload that would exceed 534 the MTU of the port the frame would otherwise be forwarded to, an 535 error notification frame MAY be generated. The generated reply MUST 536 contain the MTU error sub-code. The Outgoing Port MTU TLV MUST be 537 included with the MTU of the port the frame would have otherwise been 538 transmitted on. The Incoming Port ID TLV SHOULD be included with the 539 port ID the received frame arrived on. The Outgoing Port ID TLV 540 SHOULD be included with the port ID of the port the received frame 541 would have been forwarded onto if the frame size was not too large. 542 Finally, the error notification message SHOULD include a 16-bit 543 nickname and 48-bit system id of the next hop RBridge the frame would 544 have been sent to in the Next Hop Information TLV. If the request is 545 a multi-destination frame, the previous hop information SHOULD be 546 included instead with it set to the nickname and system id of the 547 RBridge the frame was received from. This is the previous hop 548 RBridge. If the RBridge transmitting the reply is the egress 549 RBridge, this TLV MUST NOT be included in the frame. 551 5. RBridge Channel Message Format 553 This section specifies the format of the TRILL OAM payload after the 554 RBridge Channel header and values of the fields in the RBridge 555 Channel Header [RBridgeChannel]. 557 5.1. RBridge Channel Header and Sequence Number 559 The RBridge Channel Header [RBridgeChannel] fields and flags and 560 following sequence number are as follows: 562 o CHV (Channel Header Version) is zero. 564 o Protocol code values are: 566 * 0x004 (Suggested): Echo 567 * 0x005 (Suggested): Error Notification 569 o Flags: The SL and NA bits SHOULD be zero, the MH bit SHOULD be one 571 o ERR: The ERR field MUST be zero. 573 o SPID and Sequence Number: For the Echo and Error Notification 574 protocols, the RBridge Channel Header is always followed by a 575 nibble sub-protocol identifier (SPID) and a 28-bit Sequence 576 Number. This 28-bit field is used to sequence or match frames for 577 certain uses. The SPID is used to provide additional op-code room 578 for a protocol to further multiplex its messages. Not all TRILL 579 OAM messages utilize the sequence number field or the SPID. 581 6. OAM Protocol Field Values 583 6.1. Response Frame Field Values 585 Frames with a TRILL OAM message generated in response to another 586 TRILL data frame have fields set as follows unless otherwise 587 specified: 589 o Frames of type Application or Error 591 * Field: Inner.MacSA 593 * Value: If the Inner.MacDA of the received frame is one of the 594 MAC addresses of the RBridge generating the frame, the value 595 MUST be that MAC address. Otherwise, it MUST be one of the 596 RBridge's MAC addresses. 598 o Frames of type Application or Error 600 * Field: Inner.MacDA 602 * Value: The value MUST be All-Egress-RBridges. 604 o Frames of type Application or Error 606 * Field: Inner.VLAN ID 608 * Value: If the frame is generated in response to another frame 609 with a legal Inner.VLAN ID, it MUST be the Inner.VLAN ID of the 610 received frame. In other cases, it SHOULD be the default VLAN 611 ID 1. 613 o Frames of type Application or Error 615 * Field: Ingress RBridge nickname 617 * Value: If the egress RBridge nickname of the received frame is 618 a nickname of the RBridge generating the frame, then the value 619 MUST be that nickname. otherwise, it MUST be one of the 620 RBridge's nicknames. 622 o Frames of type Application or Error 624 * Field: Egress RBridge nickname 626 * Value: The value MUST be the ingress RBridge nickname of the 627 received frame. Except that, if the ingress RBridge nickname 628 received is unknown or reserved the frame MUST be generated on 629 the port the frame was received on with an Outer.MacDA and 630 egress RBridge nickname of the previous-hop RBridge if this is 631 known. 633 o Frames of type Error 635 * Field: Offending Encapsulated Frame 637 * Value: The value MUST be N bytes of the frame that had the 638 error where N is the minimum of the frame size and the number 639 of bytes that would bring the resulting error frame up to 1470 640 bytes. This MUST include the TRILL header and MUST NOT include 641 the link-layer header. 643 o Frames of type Application 645 * Field: M Bit 647 * Value: The value of this field is defined by each specific OAM 648 protocol. 650 o Frames of type Error 652 * Field: M Bit 654 * Value: The value MUST be zero. 656 o Frames of type Application or Error 658 * Field: Inner.Priority 659 * Value: The value SHOULD be one less than the priority of the 660 received frame, but not less than the lowest priority. One 661 less may be numerically one less in the normal case or 662 logically one less in the case of priority mapping being 663 present. 665 6.2. Self-Initiated Frame Field Values 667 Frames with a TRILL OAM message that are self-initiated have fields 668 set as follows unless otherwise specified: 670 o Frames of type Application 672 * Field: Inner.MacSA 674 * Value: This SHOULD be one of the transmitting RBridge's MAC 675 addresses. The Inner.MacSA MAY be other values as specified in 676 Appendix A. 678 o Frames of type Application 680 * Field: Inner.MacDA 682 * Value: The value SHOULD be All-Egress-RBridges. 684 o Frames of type Application 686 * Field: Inner.VLAN ID 688 * Value: The value SHOULD be the default VLAN ID 1. The 689 Inner.VLAN ID MAY be other values as specified in Appendix A. 691 o Frames of type Application 693 * Field: Ingress RBridge nickname 695 * Value: The value SHOULD be one of the RBridge's nicknames. The 696 Ingress RBridge nickname MAY be other values as specified in 697 Appendix A. 699 o Frames of type Application 701 * Field: Egress RBridge nickname 703 * Value: The value of this field is defined by each specific OAM 704 protocol. 706 o Frames of type Application 708 * Field: M Bit 710 * Value: The value of this field is defined by each specific OAM 711 protocol. 713 o Frames of type Application 715 * Field: Inner.Priority 717 * Value: The value of this field defaults to zero. The 718 Inner.Priority MAY be other values as specified in Appendix A. 720 7. OAM Protocol Formats 722 The formats of Echo Request, Echo Reply, and Error Notification OAM 723 Messages are given below. 725 7.1. Protocol Application Codes Formats 727 7.1.1. Echo Request 729 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 730 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 731 | RBridge Channel | 732 | Header | 733 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 734 | SPID | Sequence | 735 | Number | 736 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 738 Echo Request 740 Figure 3 742 This message is used by ingress RBridges to request an echo reply 743 from the egress RBridge. Further uses are specified in Section 4.1.2 744 and Section 4.1.1 746 o SPID: The SPID MUST be zero to indicate an echo request. 748 o Sequence Number: An arbitrary 28-bit unsigned integer used to aid 749 in matching reply messages to echo requests. It MAY be zero. 751 7.1.2. Echo Reply 753 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 754 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 755 | RBridge Channel | 756 | Header | 757 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 758 | SPID | Sequence | 759 | Number | 760 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 761 . . 762 . TLVs . 763 . . 764 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 766 Echo Reply Format 768 Figure 4 770 This message is used by egress RBridges to reply to an echo request 771 from the ingress RBridge. Further uses are specified in 772 Section 4.1.2 and Section 4.1.1. 774 o SPID: The SPID MUST be one to indicate an echo reply. 776 o Sequence Number: A 28-bit unsigned integer used to aid in matching 777 reply messages to echo requests. Set to the sequence number field 778 of the Echo Request that cause this Echo Reply. 780 o TLVs: A set of type, length, value encoded fields as specified in 781 Section 8. 783 7.2. Error Notification Format 785 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 786 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 787 | RBridge Channel | 788 | Header | 789 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 790 | SPID | Sequence | 791 | Number | 792 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 793 | Err. T.| Subcode | 794 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 795 . . 796 . TLVs . 797 . . 798 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 800 Error Format 802 Figure 5 804 This message is used by RBridges to signal that an error has been 805 detected. 807 o SPID: The SPID MUST be set to all zeros on transmission and is 808 ignored on reception. It is unused by the error notification 809 protocol. 811 o Sequence Number: For all sub-codes except for the hop count error 812 this field is unused. It is set to zero on transmission and 813 ignored on reception. For the hop count error this is a 28-bit 814 unsigned integer used to aid in matching reply messages to echo 815 requests. If the frame whose hop-count dropped to zero contains 816 the echo request message (See Section 7.1.1), this MUST match the 817 sequence number Echo Request found in that message. If this is 818 not in reply to an Echo Request, then the sequence number MUST be 819 set to zero. 821 o Error Type: MUST be a specifier of the error type describing the 822 error. The values are: 0 (Permanent Error), 1 (Transient Error), 823 2 (Warning), 3 (Comment). Values 4 through 7 are available for 824 allocation by IETF Review. 826 o Subcode: MUST be a specifier of the error discovered in the frame. 827 The valid values are specified in Section 7.2.1 829 o TLVs: A set of type, length, value encoded fields as specified in 830 Section 8. 832 7.2.1. Error Specifiers 834 The sub-code values fall into three categories: errors (divided into 835 transient and permanent errors), warnings, and comments. All sub- 836 codes represent something out of the ordinary that has gone wrong, 837 but certain ones are more important than others. Sub-codes that are 838 classified as errors are the most severe with warning sub-codes being 839 less severe. These are enabled by default. Errors can be futher 840 divided into transient and permanent. Transient errors are errors 841 that happen but where the error causing RBridge can try again in the 842 future and the error may not happen again. Permanent errors are 843 errors that will happen again in a converged network. It is up to 844 implementations to determine if errors should be listed as permanent 845 or transient. Sub-codes classified as comments are minor and are 846 disabled by default. They may be useful for operators debugging a 847 network. All error generations are optional and therefore MAY be 848 generated or not generated depending on security and implementation 849 constraints. 851 The error specifiers sub-code values are: 853 Error Sub-codes 855 o 0: Unknown Error: Indicates an error has occurred. 857 o 1: Invalid Outer.VLAN: Indicates the Outer.VLAN ID was not the 858 designated VLAN ID or was 0xFFFF. 860 o 2: Unknown Egress RBridge: Indicates the Egress RBridge in a 861 received frame is unknown. 863 o 3: Unknown Ingress RBridge: Indicates the Ingress RBridge in a 864 received frame is unknown. (RBridges are not required to test for 865 this error.) 867 o 4: Unsupported Critical Hop-by-hop Option: Indicates an 868 unsupported critical hop-by-hop option was received. 870 o 5: Unsupported Critical Ingress-to-Egress Option: Indicates an 871 unsupported critical ingress-to-egress option was received. 873 o 6: Hop Count Zero: Indicates a frame hop count reached zero in 874 transit. (Used for pings and traceroute.) 876 o 7: Frame too Big: Indicates a frame was too large for the path it 877 took (exceeded the MTU). 879 o 8-84: Available for allocation by IETF Review 881 o 85: Reserved for Private Experimentation 883 Warning Sub-codes 885 o 86: No Adjacency: Indicates a TRILL data frame was sent from an 886 RBridge the receiving RBridge is not adjacent to. (RBridges MAY 887 be configured to accept such frames in which case this is not an 888 error.) 890 o 87-169: Available for allocation by IETF Review 892 o 170: Reserved for Private Experimentation 894 Comment Sub-codes 896 o 171-254: Available for allocation by IETF Review 898 o 255: Reserved for Private Experimentation 900 8. Type, Length, Value (TLV) Encodings 902 To facilitate future interoperable expansion of the data carried in 903 OAM sub-messages some sub-messages use a TLV encoding. These TLV 904 sections consist of a list of type, length, value encoded data where 905 the type signals to the RBridge how to interpret the value, and the 906 length tells the RBridge the length of the value in bytes. The type 907 and length are both 16 bit fields. A length of zero indicates the 908 value is a UTF-8 string with a NULL ('\0') terminating byte. 909 Preceding the list of TLVs is a 16 bit total length field which 910 specifies the total length of all the length fields in octet units. 911 TLVs with an unknown Type MUST be ignored and skipped over. The 912 value field is 1 byte aligned. 914 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 915 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 916 | Total Length | 917 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 918 . . 919 . TLV List . 920 . . 921 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 923 TLVs Format 925 Figure 6 927 Each TLV in the TLV List appears on the wire encoded as follows: 929 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 930 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 931 | Type | 932 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 933 | Length | 934 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 935 . . 936 . Value . 937 . . 938 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 940 TLV Format 942 Figure 7 944 The type values are: 946 o 0: Next Hop Information, See Section 8.1 948 o 1: Previous Hop Information, See Section 8.2 950 o 2: Outgoing Port ID, See Section 8.4 952 o 3: Incoming Port ID, See Section 8.3 954 o 4: Outgoing Port MTU, See Section 8.5 956 o 5: IS-IS System ID, See Section 8.6 957 o 6-253: Available for allocation by IETF Review 959 o 254: Reserved for Private Use 961 o 255: Reserved 963 8.1. Next Hop Information 965 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 966 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 967 | Type = 0x00 | 968 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 969 | Length = 0x08 | 970 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 971 | Next Hop Nickname | 972 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 973 | | 974 | Next Hop System ID | 975 | | 976 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 978 Next Hop Information Format 980 Figure 8 982 For traceroutes targeting known unicast destinations, hop-count 983 errors, and MTU errors, this TLV MUST be a 16-bit nickname and 48-bit 984 system ID of the next hop RBridge the frame is being or would have 985 been sent to. If the next hop RBridge has not reserved a nickname 986 the nickname field must be 0x0000. If the RBridge transmitting the 987 TLV is the egress RBridge this TLV is not included in the frame. For 988 pings, this field MUST be set to all zeros on transmission and 989 ignored on reception. If an RBridge has multiple nicknames it SHOULD 990 use the numerically largest nickname in the Next Hop Information TLV. 992 8.2. Previous Hop Information 994 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 995 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 996 | Type = 0x00 | 997 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 998 | Length = 0x08 | 999 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1000 | Previous Hop Nickname | 1001 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1002 | | 1003 | Previous Hop System ID | 1004 | | 1005 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1007 Previous Information Format 1009 Figure 9 1011 For traceroutes targeting known unicast destinations, hop-count 1012 errors, and MTU errors, this TLV MUST be a 16-bit nickname and 48-bit 1013 system ID of the previous hop RBridge the frame being responded to 1014 was forwarded from. If an RBridge has multiple nicknames it SHOULD 1015 use the numerically largest nickname in the Previous Hop Information 1016 TLV. 1018 8.3. Incoming Port ID 1020 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 1021 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1022 | Type = 0x01 | 1023 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1024 | Length = 0x02 | 1025 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1026 | Incoming Port ID | 1027 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1029 Incoming Port ID Format 1031 Figure 10 1033 This TLV MUST be set to the Port ID found in 'The Special VLANs and 1034 Flags sub-TLV' for the port the request being replied to was received 1035 on [RFC6326]. 1037 8.4. Outgoing Port ID 1039 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 1040 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1041 | Type = 0x02 | 1042 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1043 | Length = 0x02 | 1044 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1045 | Outgoing Port ID | 1046 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1048 Outgoing Port ID Format 1050 Figure 11 1052 This TLV MUST be set to the Port ID found in 'The Special VLANs and 1053 Flags sub-TLV' for the port the frame is being forwarded on to (or 1054 would have been for an echo request/hop-count error) [RFC6326]. If 1055 the request was consumed by the replying RBridge, the port ID MUST be 1056 0xFFFF. 1058 8.5. Outgoing Port MTU 1060 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 1061 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1062 | Type = 0x03 | 1063 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1064 | Length = 0x02 | 1065 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1066 | Outgoing Port MTU | 1067 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1069 Outgoing Port MTU Format 1071 Figure 12 1073 This TLV MUST be the MTU of the outgoing port specified in the 1074 outgoing port ID TLV. 1076 8.6. IS-IS System ID 1078 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15| 1079 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1080 | Type = 0x04 | 1081 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1082 | Length = 0x06 | 1083 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1084 | | 1085 | IS-IS System ID | 1086 | | 1087 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1089 IS-IS System ID Format 1091 Figure 13 1093 This TLV MUST include the IS-IS System ID of the system generating 1094 the message. This TLV MAY be included in all/any messages. 1096 9. Acknowledgments 1098 Many people have contributed to this work, including the following, 1099 in alphabetic order: Sam Aldrin, Dinesh Dutt, Donald E. Eastlake 3rd, 1100 Anoop Ghanwani, Meenakshi Kaushik, Jeff Laird, Thomas Narten, Santosh 1101 Rajagopalan, Marc Sklar, and Li Yizhou. 1103 10. IANA Considerations 1105 IANA is request to create a new subregistry within the TRILL 1106 Parameter registry for "TRILL OAM Message Error Sub-Message Error 1107 Specifiers". This subregistry that is initially populated as 1108 specified in Section 7.2.1. Additional values are allocated by IETF 1109 Review [RFC5226]. 1111 IANA is requested to create a new subregistry within the TRILL 1112 Parameter registry for "TRILL Error Reporting Protocol TLV Types" 1113 with initial values as listed in Section 5.3. Additional values are 1114 allocated by IETF Review [RFC5226]. 1116 This draft also requires action to reserve the TRILL RBridge Channel 1117 protocol codes. IANA is requested to allocate the TRILL RBridge 1118 Channel protocol codes for as listed in Section 5.1. 1120 11. Security Considerations 1122 The nature of the OAM Messages can lead to security concerns. By 1123 providing information about the topology and status of a network, 1124 attackers can gain greater knowledge of a network in order to exploit 1125 the network. Passive attacks such as reading frames with an OAM 1126 message could be used to gain such knowledge or active attacks where 1127 an attacker mimics an RBridge can be used to probe the network. 1128 Authentication, data integrity, protection against replay attacks, 1129 and confidentiality for TRILL OAM frames may be provided using a to- 1130 be-specified TRILL Security Option. Using such a security option 1131 would mitigate both the passive and active attacks. 1133 For instance, data origin authentication could be provided in the 1134 future using a security options in the TRILL Header by verifying a 1135 hash using shared keys or a mechanism like SEND with CGA. To prevent 1136 replay attacks rate limiting, sequence numbers as well as some nonce 1137 based mechanism could be provided. Confidentiality for TRILL OAM 1138 frames could be provided based on some future security option 1139 extension which encypts TRILL frames. 1141 In a network where one does not wish to configure a security option, 1142 the threat of attackers is still present. For this reason, 1143 generation of any TRILL OAM Message frames is optional and SHOULD be 1144 configurable by an operator on a per RBridge basis. An RBridge MAY 1145 have this configurable on a per port basis. For instance, an 1146 operator SHOULD be able to disable hop-count traceroute reply 1147 messages or error notification message generation per port. 1149 Another security threat is denial of service through use of OAM 1150 messages. For this reason, RBridges MUST rate limit the generation 1151 of OAM message frames. For multi-destination frames, the frames MAY 1152 be discarded silently to prevent any denial of service attacks in 1153 case of an error packet such as an 'options not recognized' error 1154 notification. 1156 12. References 1158 12.1. Normative References 1160 [RBridgeChannel] Eastlake, D., Manral, V., Yizhou, L., Aldrin, S., 1161 and D. Ward, "RBridges: TRILL RBridge Channel 1162 Support", draft-ietf-trill-rbridge-channel-05 (work 1163 in progress), February 2012. 1165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1166 Requirement Levels", BCP 14, RFC 2119, March 1997. 1168 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., 1169 Romascanu, D., and S. Mansfield, "Guidelines for 1170 the Use of the "OAM" Acronym in the IETF", BCP 161, 1171 RFC 6291, June 2011. 1173 [RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and 1174 A. Ghanwani, "Routing Bridges (RBridges): Base 1175 Protocol Specification", RFC 6325, July 2011. 1177 12.2. Informative References 1179 [BFD] Banerjee, A., Ward, D., Eastlake, D., and V. 1180 Manral, "Rbridges: Bidirectional Forwarding 1181 Detection (BFD) support for TRILL", 1182 draft-ietf-trill-rbridge-bfd-02 (work in progress), 1183 January 2012. 1185 [IEEE.802-1ag] Institute of Electrical and Electronics Engineers, 1186 "IEEE Stadard for Local and metropolitian area 1187 networks / Virtual Bridged Local Area Networks / 1188 Connectivity Fault Management", IEEE Standard 1189 802.1Q, December 2007. 1191 [IS-IS] International Organization for Standardization, 1192 "Intermediate system to intermediate system intra- 1193 domain-routing routine information exchange 1194 protocol for use in conjunction with the protocol 1195 for providing the connectionless-mode Network 1196 Service (ISO 8473)", ISO/IEC 10589:2002, Second 1197 Edition, Nov 2002. 1199 [RBridgeMIB] Rijhsinghani, A. and K. Zebrose, "Definitions of 1200 Managed Objects for RBridges", 1201 draft-ietf-trill-rbridge-mib-06 (work in progress), 1202 January 2012. 1204 [RFC0792] Postel, J., "Internet Control Message Protocol", 1205 STD 5, RFC 792, September 1981. 1207 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet 1208 Control Message Protocol (ICMPv6) for the Internet 1209 Protocol Version 6 (IPv6) Specification", RFC 4443, 1210 March 2006. 1212 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for 1213 Writing an IANA Considerations Section in RFCs", 1214 BCP 26, RFC 5226, May 2008. 1216 [RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and 1217 JR. Rivers, "Extending ICMP for Interface and Next- 1218 Hop Identification", RFC 5837, April 2010. 1220 [RFC6165] Banerjee, A. and D. Ward, "Extensions to IS-IS for 1221 Layer-2 Systems", RFC 6165, April 2011. 1223 [RFC6326] Eastlake, D., Banerjee, A., Dutt, D., Perlman, R., 1224 and A. Ghanwani, "Transparent Interconnection of 1225 Lots of Links (TRILL) Use of IS-IS", RFC 6326, 1226 July 2011. 1228 Appendix A. Implementation Considerations 1230 This appendix contains a few considerations implementors should take 1231 note of when creating their user interface as well as some examples 1232 of what occurs when a traceroute or ping are executed. These provide 1233 a sample user interface one can use as the basis for their user 1234 interface. 1236 First, an RBridge SHOULD maintain counters for each type of error 1237 generated. There SHOULD be a way for users to view these counters. 1239 Some of the set of default field values for self originated frames 1240 are presented in Section 6.2. RBridges SHOULD be configurable to 1241 change these values to assign the TRILL data frame to a flow. 1243 A.1. Hop Count Traceroute Example 1245 Figure 14 contains a campus with three RBridges. Consider a hop- 1246 count traceroute from RB0 to RB2. 1248 +-----+ +-------+ +-------+ +-------+ +-----+ 1249 | ESa +--+ RB0 +---+ RB1 +---+ RB2 +--+ ESb | 1250 +-----+ |ingress| |transit| |egress | +-----+ 1251 +-------+ +-------+ +-------+ 1253 Time RB0 RB1 RB2 1254 . (1)-------> | | 1255 . | <------- (2) | 1256 . (3)-------> (3) -------> | 1257 . | <------- (4) <-------(4) 1259 Hop Count Traceroute Example Topology 1261 Figure 14 1263 In this diagram RB0 transmits frame (1) destined to RB2. This frame 1264 contains the echo request message and a hop-count of 0. When RB1 1265 receives this frame it drops it and transmits a hop-count-exceeded 1266 message, (2), to RB0. RB0 then transmits a frame, (3), with a hop- 1267 count of 1. RB1 decrements this hop-count by 1 to 0 and forwards it 1268 to RB2. RB2 drops frame (3) and transmits a Hop Count Zero error 1269 notification, (4), to RB0. The traceroute is now complete. 1271 Below are some select fields for the frames: 1273 +-------+----------+----------+----------------+----------+---------+ 1274 | Frame | Ingress | Egress | TRILL OAM | Sequence | Hop | 1275 | # | RBridge | RBridge | Protocol | Number | Count | 1276 +-------+----------+----------+----------------+----------+---------+ 1277 +-------+----------+----------+----------------+----------+---------+ 1278 | (1) | RB0 | RB2 | Echo Request | 1 | 0 | 1279 +-------+----------+----------+----------------+----------+---------+ 1280 | (2) | RB1 | RB0 | Hop Count Zero | 1 | Default | 1281 | | | | error | | | 1282 | | | | notification | | | 1283 +-------+----------+----------+----------------+----------+---------+ 1284 | (3) @ | RB0 | RB2 | Echo Request | 2 | 1 | 1285 | RB1 | | | | | | 1286 +-------+----------+----------+----------------+----------+---------+ 1287 | (3) @ | RB0 | RB2 | Echo Request | 2 | 0 | 1288 | RB2 | | | | | | 1289 +-------+----------+----------+----------------+----------+---------+ 1290 | (4) @ | RB2 | RB0 | Hop Count Zero | 2 | Default | 1291 | RB1 | | | error | | | 1292 | | | | notification | | | 1293 +-------+----------+----------+----------------+----------+---------+ 1294 | (4) @ | RB2 | RB0 | Hop Count Zero | 2 | Default | 1295 | RB0 | | | error | | | 1296 | | | | notification | | | 1297 +-------+----------+----------+----------------+----------+---------+ 1299 Table 1: Hop Count Traceroute Example Frames 1301 For example, if the nicknames for RB0, RB1, and RB2 are 0x1111, 1302 0x2222, and 0x3333 respectively, the console output from such a trace 1303 might be: 1305 Hop Count Tracing 1307 RBridge Incoming Port Id Outgoing Port Id RBridge Nexthop Nickname 1308 ------- ---------------- ---------------- ------------------------ 1309 0x1111 Ingress 0x0001 0x2222 1310 0x2222 0x0000 0x0001 0x3333 1311 0x3333 0x0000 Egress 0x0000 1313 Table 2: Hop Count Traceroute Example Output 1315 In this example, the first line of output is generated from local 1316 information, no hop-count frames are sent to generate it. 1318 A.2. Ping Example 1320 Figure 15 contains a campus with three RBridges. Consider a ping 1321 from RB0 to RB2. 1323 +-----+ +-------+ +-------+ +-------+ +-----+ 1324 | ESa +--+ RB0 +---+ RB1 +---+ RB2 +--+ ESb | 1325 +-----+ |ingress| |transit| |egress | +-----+ 1326 +-------+ +-------+ +-------+ 1328 Time RB0 RB1 RB2 1329 . (1)-------> (1) -------> | 1330 . | <------- (2) <-------(2) 1332 Ping Example Topology 1334 Figure 15 1336 In this diagram RB0 transmits frame (1) destined to RB2. This frame 1337 contains the echo request message. When RB1 receives this frame it 1338 forwards it to RB2. When RB2 receives this frame it transmits and 1339 echo reply frame (2) destined to RB0. RB1 receives this frame and 1340 forwards it to RB0. 1342 Below are some select fields for the frames: 1344 +--------+-------------+-------------+---------------+--------------+ 1345 | Frame | Ingress | Egress | TRILL OAM | Sequence | 1346 | # | RBridge | RBridge | Protocol | Number | 1347 +--------+-------------+-------------+---------------+--------------+ 1348 +--------+-------------+-------------+---------------+--------------+ 1349 | (1) | RB0 | RB2 | Echo Request | 1 | 1350 +--------+-------------+-------------+---------------+--------------+ 1351 | (2) | RB2 | RB0 | Echo Reply | 1 | 1352 +--------+-------------+-------------+---------------+--------------+ 1354 Table 3: Ping Example Frames 1356 For example, if the nicknames for RB0, RB1, and RB2 are 0x1111, 1357 0x2222, and 0x3333 respectively, the console output from such a ping 1358 might be: 1360 Pinging 1361 -------------------------------------------- 1362 ... from 0x1111 to 0x3333... 0x3333 is alive 1363 ... from 0x1111 to 0x3333... 0x3333 is alive 1364 ... from 0x1111 to 0x3333... 0x3333 is alive 1366 Table 4: Ping Example Output 1368 In this example, the ping was repeated three times with the sequence 1369 number (not shown) being changed each time. 1371 Appendix B. Revision History 1373 RFC Editor: Please delete this appendix before publication. 1375 B.1. Changes from -01 to -02 1377 Moved the values table to the message format section and converted 1378 from table to list. 1380 Added previous hop information TLV. 1382 Removed error codes that were not needed. 1384 Added path sharing traceroute with 'real' data being sent. 1386 Added mention of BFD draft. 1388 Made most TLVs optional to allow hardware/fast path 1389 implementations where this information might not be available. 1391 Changed Next Hop Nickname TLV into Next Hop Information TLV since 1392 next hop might not always reserve a nickname. The new TLV 1393 includes the next hop system id. 1395 Numerous minor typo corrections and wording clarifications. 1397 B.2. Changes from -00 to -01 1399 Broke down the table "frame field values" into two tables, 1400 "response frame field values" and "self initiated frame field 1401 values". 1403 Reorganized the document to move user interface related items to 1404 the appendix and switched the order of ping/traceroute. 1406 Numerous minor typo corrections and wording clarifications. 1408 Authors' Addresses 1410 David Michael Bond 1411 International Business Machines 1412 2051 Mission College Blvd. 1413 Santa Clara, CA 95054 1414 US 1416 Phone: +1-603-339-7575 1417 EMail: mokon@mokon.net 1418 URI: http://mokon.net 1420 Vishwas Manral 1421 Hewlett-Packard Co. 1422 19111 Pruneridge Ave. 1423 Cupertino, CA 95014 1424 US 1426 Phone: +1-408-447-0000 1427 EMail: vishwas.manral@hp.com