idnits 2.17.1 draft-tissa-trill-8021ag-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 10.2 IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2012) is 4295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TRLOAMREQ' is mentioned on line 117, but not defined == Unused Reference: '8021Q' is defined on line 942, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-tissa-trill-oam-03 == Outdated reference: A later version (-21) exists of draft-eastlake-fnv-03 == Outdated reference: A later version (-02) exists of draft-tissa-trill-multilevel-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Tissa Senevirathne 2 Internet Draft Samer Salam 3 Intended status: Informational CISCO 5 Donald Eastlake 6 Sam Aldrin 7 HuaWei 9 Naveen Nimmu 10 Broadcom 12 Tal Mizrahi 13 Marvell 15 Anoop Ghanwani 16 Dell 18 June 25, 2012 19 Expires: December 2012 21 Use of 802.1ag for TRILL OAM messages 22 draft-tissa-trill-8021ag-00.txt 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on December 25, 2012. 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Abstract 64 In this document we present definitions of TRILL OAM messages. 65 Messages defined in this document follow a similar structure to IEEE 66 802.1ag messages. In this document, only the high level proposal on 67 using IEEE 802.1ag messaging is presented. The goal is to facilitate 68 discussion on feasibility of using IEEE 802.1ag messages for TRILL 69 OAM. Based on feedback from TRILL WG and IEEE 802.1 group, this 70 document may be further updated. 72 Table of Contents 74 1. Introduction...................................................3 75 1.1. Objective.................................................4 76 2. Conventions used in this document..............................4 77 3. TRILL OAM Model................................................4 78 3.1 OAM Layering.............................................4 79 3.2 TRILL OAM in RBridge Port Model..........................5 80 3.3 Maintenance Domains......................................6 81 3.4 MEPs and MIPs............................................7 82 4. TRILL OAM Message channel......................................9 83 4.1. TRILL OAM Message header.................................10 84 4.1.1. Use of Magic Number and Checksum....................11 85 4.2. TRILL OAM Opcodes........................................11 86 4.3. Format of TRILL OAM Message TLV..........................12 87 4.4. TRILL OAM TLV............................................13 88 4.4.1. Common TLV between 802.1ag and TRILL................13 89 4.4.2. TRILL OAM TLV.......................................13 90 4.4.2.1. TRILL OAM Version TLV..........................13 91 4.4.3. Out Of Band IP Address TLV..........................15 92 4.4.3.1. Diagnostics VLAN TLV...........................15 93 4.4.3.2. Original Data Payload TLV......................16 94 5. Loopback Message..............................................16 95 5.1.1. Loopback OAM Message format.........................17 96 5.1.2. Theory of Operation.................................17 97 5.1.2.1. Originator RBridge.............................17 98 5.1.2.2. Intermediate RBridge...........................18 99 5.1.2.3. Destination RBridge............................18 100 5.2. Loopback Message Hop-count method........................19 101 5.2.1. Prevent leaking out from TRILL network..............19 102 6. Path Trace Message............................................19 103 7. Notification Messages.........................................19 104 8. Status Codes..................................................20 105 8.1. Error Codes..............................................20 106 8.2. Warning Codes............................................20 107 8.3. Informational Codes......................................21 108 9. Security Considerations.......................................21 109 10. IEEE Considerations................Error! Bookmark not defined. 110 11. References...................................................21 111 11.1. Normative References....................................21 112 11.2. Informative References..................................22 113 12. Acknowledgments..............................................22 115 1. Introduction 117 The structure of TRILL OAM messages is presented in [TRLOAMREQ]. 118 Accordingly, TRILL OAM messages are constitute of four main parts; 119 outer header, TRILL header, Flow Entropy and OAM message channel. 121 OAM Message channel allows defining various control information and 122 carrying additional OAM related data between TRILL switches, also 123 known as RBridges or Routing Bridges. 125 Outer header, TRILL header and Flow Entropy are technology (standard 126 organization) dependent. OAM message channel, if defined properly, 127 can be shared between different technologies. A common OAM channel 128 allow a uniform user experience to the customers, savings on 129 operator training, re-use of software code base and faster time to 130 market. 132 In this document we propose to base the message channel on the 133 [802.1ag] messaging format as defined in IEEE Connectivity Fault 134 Management (CFM) [802.1ag] [802.1Q]. 136 The ITU-T Y.1731 standard utilizes the same messaging format as 137 [802.1ag]. However, IEEE defines a separate op-code space for the 138 applicable messages specific to Y.1731. We propose a similar 139 approach for TRILL and request a separate code space to be assigned 140 for TRILL OAM messages. 142 1.1. Objective 144 The Objective of this document is to solicit feedback and comments 145 on the use of 802.1ag messaging format as the OAM message format for 146 TRILL. This document does not go into the operational details. 147 Operational details are very similar to [TLICMPOAM]. Readers are 148 referred to [TLICMPOAM] for details of operational aspects. 150 Updated and revised version of this document may be published in the 151 future based on the feedback and comments of TRILL WG and IEEE 802.1 152 group. 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in RFC-2119 [RFC2119]. 160 3. TRILL OAM Model 162 3.1. OAM Layering 164 In the RBridge architecture, the TRILL layer is independent of the 165 underlying Link Layer technology. Therefore, it is possible to run 166 TRILL over any transport layer capable of carrying Layer 2 frames 167 such as Ethernet, PPP, or MPLS (Pseudo Wire). Furthermore, TRILL 168 provides a virtual Ethernet connectivity service that is transparent 169 to higher layer entities (e.g. Layer 3 and above). This strict 170 layering is observed by TRILL OAM. 172 Of particular interest is the layering of TRILL OAM with respect to 173 Ethernet CFM [802.1ag], especially that TRILL switches are likely to 174 be deployed alongside existing 802.1 bridges in a network. Consider 175 the example network depicted in Figure 1 below: 177 LAN 178 o-o-o-o-o-oo 179 +---+ +---+ +---+ +---+ o o +---+ 180 +--+ | | | | | | | | +--+ +--+ | | +--+ 181 |B1|--|RB1|--|RB2|- |RB3| -|RB4|-o|B3|--|B4|o-|RB5|--|B5| 182 +--+ | | | | | | | | +--+ +--+ | | +--+ 183 +---+ +---+ +---+ +---+ o o +---+ 184 o-o-o-o-o-oo 186 <-X-----X-----------X-----------------X-> TRILL OAM 188 <-X-----X-----------------------X--X------X-------X--X-> Ethernet 189 CFM 191 Figure 1: TRILL OAM & Ethernet CFM Layering 193 Where Bn and RBn (n= 1,2,3,4,5) denote IEEE 802.1 bridges and TRILL 194 RBridges, respectively. 196 The "X" marks in the figure above indicate where each OAM protocol 197 is applicable in the context of an example TRILL network. Note that 198 this simplified diagram is not meant to capture the CFM Maintenance 199 domain hierarchy nor the locality of MEPs/MIPs of various 200 technologies. It is worth noting that an RBridge may actively 201 participate in CFM only when connected to an 802.1 LAN. Transient 202 RBridges, in the core of a TRILL network, with no direct 203 connectivity to 802.1 LAN are completely transparent to CFM. 205 3.2. TRILL OAM in RBridge Port Model 207 TRILL OAM processing can be modeled as a client of the Enhanced 208 Internal Sublayer Service (EISS) in [802.1Q]. Furthermore, TRILL OAM 209 requires services of the RBridge forwarding engine and utilizes 210 information from the IS-IS control plane. Figure 2 below depicts 211 TRILL OAM processing in the context of the RBridge port model 212 defined in [RFC6325]. In this figure, double lines represent flow of 213 both frames and information whereas single lines represent flow of 214 information only. 216 While this figure shows a conceptual model, it is to be understood 217 that implementations need not mirror this exact model as long as the 218 intended OAM requirements and functionality are preserved. 220 +----------------------------------------- 221 | RBridge 222 | 223 | Forwarding Engine, IS-IS, Etc. 224 | Processing of native and TRILL frames 225 | 226 +---++------------++------+--------------- 227 +-------------+| || | other ports... 228 |+-------------+ +--------++ | 229 || /+--------++ | 230 +--------++-------------+ // || | 231 | |// || | 232 | +/ +----++------+ | <- EISS 233 | TRILL OAM + | | | 234 | Processing | | 802.1Q | | 235 | | | Port VLAN | | 236 +-----------------------+ | Processing | | 237 | | | 238 +------------------------------+------------+-++ <-- ISS 239 | | 240 | 802.1/802.3 Low Level Control Frame | 241 | Processing, Port/Link Control Logic | 242 | | 243 +-----------++---------------------------------+ 244 || 245 || +------------+ 246 || | 802.3 PHY | 247 |+--------+ (Physical +--------- 802.3 248 +---------+ Interface) +--------- Link 249 | | 250 +------------+ 252 Figure 2: TRILL OAM in RBridge Port Model 254 3.3. Maintenance Domains 256 The concept of Maintenance Domains, or OAM Domains, is well known in 257 the industry. IEEE 802.1ag, RFC6136, RFC5654, etc... all define the 258 notion of a Maintenance Domain as a collection of devices (e.g. 259 network elements) that are grouped for administrative and/or 260 management purposes. Maintenance domains usually delineate trust 261 relationships, varying addressing schemes, network infrastructure 262 capabilities, etc... 264 When mapped to TRILL, a Maintenance Domain is defined as a 265 collection of RBridges in a network for which faults in connectivity 266 or performance are to be managed by a single operator. All RBridges 267 in a given Maintenance Domain are, by definition, owned and operated 268 by a single entity (e.g. an enterprise or a data center operator, 269 etc...). RFC6325 defines the operation of TRILL in a single IS-IS 270 area, with the assumption that the network is managed by a single 271 operator. In this context, a single (default) Maintenance Domain is 272 sufficient for TRILL OAM. 274 However, when considering scenarios where different TRILL networks 275 need to be interconnected, for e.g. as discussed in [TRILLML], then 276 the introduction of multiple Maintenance Domains and Maintenance 277 Domain hierarchies becomes useful to map and contain administrative 278 boundaries. When considering multi-domain scenarios, the following 279 rules must be followed: 280 TRILL OAM domains MUST NOT overlap, but MUST either be disjoint or 281 nest to form a hierarchy (i.e. a higher Maintenance Domain MAY 282 completely include a lower Domain). A Maintenance Domain is 283 typically identified by a Domain Name and a Maintenance Level (a 284 numeric identifier). The larger the Domain, the higher the Level. 286 +-------------------+ +---------------+ +-------------------+ 287 | | | | | | 288 | Site 1 | | TRILL | | Site 2 | 289 | TRILL |--| Inter site |---| TRILL | 290 | | | Interconnect | | | 291 | | | Layer | | | 292 +-------------------+ +---------------+ +-------------------+ 294 <------------------------End-to-End Domain---------------------> 296 <----Site Domain----> <----Site Domain----> 298 Figure 3: TRILL OAM Maintenance Domains 300 3.4. MEPs and MIPs 301 OAM capabilities on RBridges can be defined in terms of logical 302 groupings of functions that can be categorized into two functional 303 objects: TRILL Maintenance End Points (MEPs) and TRILL Maintenance 304 Intermediate Points (MIPs). 306 MEPs are the active components of TRILL OAM: MEPs source TRILL OAM 307 messages proactively or on-demand based on operator invocation. 308 Furthermore, MEPs ensure that TRILL OAM messages do not leak outside 309 the TRILL network and into end stations. MIPs, on the other hand, 310 are internal to a Maintenance Domain. They are the passive 311 components of TRILL OAM, primarily responsible for forwarding TRILL 312 OAM messages and selectively responding to a subset of these 313 messages. 315 The following figure shows the MEP and MIP placement for the 316 Maintenance Domains depicted in Figure 3 above. 318 TRILL Site 1 TRILL Site 2 319 +-------------------+ +---------------+ +-------------------+ 320 | | | | | | 321 | +---+ +---+ | | TRILL | | +---+ +---+ | 322 | |RB1|-------|RB2| |--| Inter site |---| |RB3|-------|RB4| | 323 | +---+ +---+ | | Interconnet | | +---+ +---+ | 324 | | | Layer | | | 325 +-------------------+ +---------------+ +-------------------+ 327 329 331 333 Legend E: MEP I: MIP 335 Figure 4: MEPs and MIPs 337 [802.1ag] specifies two distinct MP (Maintenance Points). Namely, Up MP 338 and Down MP. [RFC6325] defines identification of TRILL frames received 339 from the wire only. It does not define methods to identify frames 340 egress in to the wire. Due to these reasons and to maintain simplicity, 341 we propose only to define Down MP for TRILL OAM. 343 MEP/MIP of different technologies may exist on a given interface. Where 344 applicable and Platforms MUST have capability to identify the 345 applicable MIP/MEP. 347 3.5. TRILL OAM Maintenance Point (MP) Addressing 349 For unicast frames, TRILL MP is addressed by its TRILL nickname and 350 either OAM Inner.MacSA or OAM Ethtype (Figure 5). 352 For multicast frames, TRILL MP is addressed by either Reserved 353 Ethtype or Reserved source MAC (Figure 5). 355 For frames that include unmodified payloads, TRILL MP is addressed 356 by its TRILL nickname, Hop-Count=0 (Figure 5). (NOTE: ingress 357 RBridge set Hop-Count such that it count out at the intended 358 RBridge). OAM signature allows OAM packets to be differentiated 359 from data packets with Hop-Count=0 361 Following table summarizes the identification of different OAM 362 frames from data frames. 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 |Flow Entropy |OAM SRC |OAM Eth |OAM |RBridge |Hop | 366 | |MAC |Type |Signature|nickname |Count=0 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 |unicast L2 | N/A |Match |Optional |Match |N/A | 369 | | | | | | | 370 |Multicast L2 | N/A |Match |Optional |N/A |N/A | 371 | | | | | | | 372 |Unicast IP | Match |N/A |Optional |Match |N/A | 373 | | | | | | | 374 |Multicast IP | Match |N/A |Optional |N/A |N/A | 375 | | | | | | | 376 |Notification | N/A |Match |Optional |Match |N/A | 377 | | | | | | | 378 |unmodified | N/A |N/A |Match |Match |Match | 379 |Payload | | | | | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 5 Identification of OAM frames 384 4. TRILL OAM Message Channel 386 TRILL OAM Message Channel can be divided in to two parts. TRILL OAM 387 Message header and TRILL OAM Message TLVs. Every OAM Message MUST 388 contain a single TRILL OAM message header and set of one or more 389 specified OAM Message TLVs. 391 4.1. TRILL OAM Message header 393 As discussed earlier, we propose to use the Message format defined 394 in 802.1ag with some modifications. We believe these modifications 395 facilitate a common messaging framework between [802.1ag], TRILL and 396 other similar standards such as Y 1.731 and RFC6136 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Magic Number | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Checksum | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | | 406 . Opcode Specific Information . 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 . TLVs . 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 6 OAM Message Format 416 o MD-L : Maintenance Domain Level (3 bits). Identifies the 417 maintenance domain level. For TRILL this MAY be always set to 418 zero. However, in MULTILEVEL TRILL, backbone MAY be of a 419 different MD-LEVEL. (Please refer to [802.1ag] for the 420 definition of MD-Level) 422 o Version. Indicates the version (5 bits). [8021ag] set version 423 to zero. 425 o Flags: Include operational flags (1 byte). The definition of 426 flags are opcode specific and is covered in the applicable 427 sections. 429 o FirstTLVOffset: Defines the location of the first TLV, in 430 bytes, starting from the end of the FirstTLVOffset field. (1 431 byte) (Please refer to [802.1ag] for the definition of the 432 FirstTLVOffset) 434 o Magic Number: Increase the Entropy of the OAM checksum. 435 Currently set to value (0x54729F74). (4 bytes). 437 Checksum : Calculated over MD-L, Version, OpCode, Flags, 438 FirstTLVOffset. Checksum is calculated using FNV32 algorithm 439 specified in [FNV]. (4 bytes). 441 NOTE: Prior to calculating the checksum, implementations MAY pre 442 validate the received frame by comparing the Version and Magic 443 Number fields. Checksum is calculated only on frames that pass the 444 pre-validation cheks. 446 MD-L, Version, Opcode, Flags, FirstTLVOffset, Magicnumber and 447 Checksum fields collectively are referred to as the OAM Message 448 Header. 450 Opcode specific information section, based on the opcode, contains 451 sequence number, time-stamp etc. Details about the Opcode specific 452 information section and the associated TLVs are presented in other 453 related documents. 455 4.1.1. Use of Magic Number and Checksum 457 The TRILL OAM framework requires the ability to differentiate 458 between OAM packets and data packets. It is possible that 459 applications may use real packets as the flow entropy. In such 460 events, a reliable signature with a high degree of accuracy is 461 required to differentiate between OAM and data packets. Version 462 number is a 5 bit field and may not be adequate enough for this 463 purpose. Implementations are required to first check for the 464 matching Version number followed by the magic number. The checksum 465 is calculated only if both the version and the checksum fields match 466 the expected values. This procedure allows implementations 467 (especially hardware) to execute checksum calculation process only 468 on packets with higher probability of being an OAM packet. Packets 469 with matching Version, Magic Number and Chescksum fields are 470 considered to be OAM packets. 472 As pointed out earlier and summarized in Figure 5, OAM signature 473 validation is performed only on frames that were identified as OAM 474 frames by the way of matching specific fields in the frame. 476 4.2. TRILL OAM Opcodes 478 We propose to define the following op-codes for TRILL. Each of the 479 opcode defines a separate TRILL OAM message. Details of the messages 480 are presented in the related sections. In this document we only 481 define a selected few OAM messages. Based on the discussions and 482 feedback, remaining OAM messages will be defined in future versions 483 of this document. 485 TRILL OAM Message codes: 487 64 : Loopback Message Reply 488 65 : Loopback Message 489 66 : Path Trace Reply 490 67 : Path Trace Message 491 68 : Notification Message 492 69 : Multicast Tree Verification Reply 493 70 : Multicast Tree Verification Message 494 71 : Loopback with Hop-count Reply 495 72 : Loopback with Hop-count Message. 496 73 : Performance Measurement one-way Reply 497 74 : Performance Measurement one-way Message 498 75 : Performance Measurement two-way Reply 499 76 : Performance Measurement two-way Message 500 77 - 95 : Reserved 502 4.3. Format of TRILL OAM Message TLV 504 We propose to use the same format as defined in section 21.5.1 of 505 [802.1ag]. Following figure depicts the general format of TRILL OAM 506 Message TLV. 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | | 512 . Value(variable) . 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 7 TRILL OAM Message TLV 518 Type (1 octet) : Specifies the Type of the TLV (see sections 4.4. 519 4.4.1. 4.4.2. for TLV types). 521 Length (2 octets) : Specifies the length of the values field in 522 octets. Length of the value field can be either zero or more octets. 524 Value (variable): Length and the content of the value field depends 525 on the type of the TLV. Please refer to applicable TLV definitions 526 for the details. 528 Semantics and usage of Type values allocated for the TRILL OAM 529 purpose are defined by this document and other future related 530 documents. 532 4.4. TRILL OAM TLV 534 In this section we define the related TLVs. We propose to re-use 535 [802.1ag] defined TLVs where applicable. Types 32-63 are reserved 536 for ITUT Y.1731. We propose to reserve Types 64-95 for the purpose 537 of TRILL OAM TLVs. 539 4.4.1. Common TLV between 802.1ag and TRILL 541 Following TLVs are defined in [802.1ag], we propose to re-use them 542 where applicable. Format and semantics of the TLVs are as defined in 543 [802.1g]. NOTE: Presented within brackets is the corresponding Type. 545 1. End TLV (0) 546 2. Sender ID TLV (1) 547 3. Port Status TLV (2) 548 4. Data TLV (3) 549 5. Interface Status TLV (4) 550 6. Reply Ingress TLV (5) 551 7. Reply Egress TLV (6) 552 8. LTM Egress Identifier TLV (7) 553 9. LTR Egress Identifier TLV (8) 554 10. Reserved (9-30) 555 11. Organization specific TLV (31) 557 4.4.2. TRILL OAM TLV 559 As indicated above, Types 64-95 will be requested to be reserved for 560 TRILL OAM purpose. Listed below, a summary of TRILL OAM TLV and the 561 corresponding codes. Format and semantics of TRILL OAM TLVs are 562 defined in subsequent sections. 564 1. TRILL OAM Version (64) 565 2. Out of Band IP Address (65) 566 3. Diagnostic VLAN (66) 567 4. RBridge scope (67) 568 5. Original Payload TLV (68) 569 6. Reserved (69-95) 571 NOTE: Above is only for illustration purposes. In future revisions 572 of this document, additional TLVs defined in [TLICMPOAM] will be 573 defined within the above TLV space. 575 4.4.2.1. TRILL OAM Version TLV 577 TRILL OAM version can be different than the [802.1ag] version 578 specified. TRILL OAM TLV specifies the TRILL OAM version. TRILL OAM 579 TLV MUST be the first TLV in TRILL OAM messages. Messages that do 580 not include TRILL OAM TLV as the first TLV MUST be discarded. 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type | Length | Version | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 |Class| Code | Reserved |F|C|O|I| 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 8 TRILL OAM Message TLV 590 Type (1 octet) = 64 indicate that this is the TRILL OAM Version 592 Length (2 octets) = 6 594 Version (1 Octet), currently set to zero. Indicates the TRILL OAM 595 version. TRILL OAM version can be different that the [802.1ag] 596 version. 598 Class (3 bits): Only applicable to Response and Notification 599 messages. 601 0 : Success 603 1 : Error 604 2 : Warning 605 3 : Info 606 4 : 7 Reserved 608 Code (13 bits): Defined within the context of a class. Please see 609 section Codes below for details. 611 Reserved: set to zero on transmission and ignored on reception. 613 F (1 bit) : Final flag, when set, indicates this is the last 614 response. 616 C (1 bit ): Cross connect error (VLAN mapping error), if set 617 indicates VLAN cross connect error detected. This field is ignored 618 in request messages and MUST only be interpreted in response 619 messages. 621 O (1 bit) : If set, indicates, OAM out-of-band response requested. 623 I (1 bit) : If set, indicates, OAM in-band response requested. 625 NOTE: When both O and I bits are set to zero, indicates that no 626 response is required. (silent mode). User MAY specify both O and I 627 or one of them or none. 629 4.4.3. Out Of Band IP Address TLV 631 Out of Band IP Address TLV specifies the IP address to which out of 632 band response MUST be sent. When O bit in the Version TLV is not 633 set, Out of Band IP Address TLV is ignored. Length of the TLV 634 implies the IP Address version. 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type | Length | Reserved | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | | 640 . IP Address . 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 9 Out of Band IP Address TLV 646 Type (1 octet) = 64 indicate that this is the TRILL OAM Version 648 Length (2 octets) = 5 or 17. Length Value 5 indicates it is IPv4 649 address and Length value of 17 indicates that it is IPv6 address. 651 IP Address (4 or 16 octets), valid IP addrss. 653 4.4.3.1. Diagnostics VLAN TLV 655 Diagnostic VLAN specifies the VLAN in which the OAM messages are 656 generated on. Receiving RBridge MUST compare the inner.VLAN of the 657 Flow entropy to the VLAN specified in the Diagnostic VLAN TLV. Cross 658 connect Flag in the response MUST be set when the two VLANs do not 659 match. 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Type | Length | V-Type | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Reserved | Label(VLAN) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 10 Diagnostic VLAN TLV 669 Type (1 octet) = 65 indicates that this is the TRILL Diagnostic 670 VLAN TLV 672 Length (2 octets) = 5 674 V-Type (1 octet) 0- indicate 802.1Q 12 bit VLAN. 676 1 - indicate TRILL 24 bit fine grain label 678 Label (24 bits): Either 12 bit VLAN or 24 bit fine grain label. 680 4.4.3.2. Original Data Payload TLV 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 685 | | 686 . Original Payload . 687 | | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Figure 11 Out of Band IP Address TLV 692 Length (2 octets) = variable 694 5. Loopback Message 696 Loopback message is utilized for fault verification. It verifies 697 connectivity between two RBridges, for a specified flow. Monitoring 698 subsystem may use Loopback Message for connectivity monitoring and 699 proactive fault detection. Users may specify exact flow, part of it 700 or not at all. Additionally, users may also specify, ECMP choice at 701 the ingress. ECMP choice can be a specific outgoing interface index, 702 set of interface indexes, all of the interface indexes or none. If 703 no ECMP index specified, payload is used to determine the ECMP 704 choice. Method of deriving the ECMP choice using payload is 705 implementation dependent and is outside the scope of this document. 706 However, an implementation generating the Loopback message SHOULD 707 use the same ECMP selection algorithm as the data plane. 708 Additionally some implementation may allow users to specify the 709 ingress interface that actual flow may ingress to the RBridge. 710 Although ability to inject the data plane diagnostic frames from the 711 ingress interface is an optional feature, it is highly desirable, as 712 it allows verifying end-to-end connectivity from an ingress port to 713 an egress RBridge. 715 Egress RBridge can send its response either in-band or out-of-band. 716 In-band-response, additionally, allows measurement of the round trip 717 delay. In-band responses are tagged with the same VLAN as the 718 request frame. TRILL OAM TLVs in the request message allow the user 719 to specify whether out-of-band response required. If out-of-band 720 response is required, IP address to which the response is to be 721 directed MUST be specified. 723 Additionally, diagnostic VLAN, may be specified. Receiver RBridge 724 may compare inner VLAN in the payload and the specified diagnostic 725 VLAN. If the two specified VLAN values do not match, C flag in 726 Version TLV SHOULD be set to indicate cross connect error. 728 5.1.1. Loopback OAM Message format 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Magic Number | Checksum | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Session Identification Number | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | | 738 . TLVs . 739 | | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 12 Loopback OAM Message Format 744 The above figure depicts the format of the Loopback Request and 745 response messages. Opcode for Loopback Request Messages is set to 64 746 and Opcode of Response Message is set to 65. Session Identification 747 Number is a 32 bit integer that allows the requesting RBridge to 748 uniquely identify the corresponding session. Responding RBridges 749 MUST echo the received "Session Identification" number without 750 modifications 752 5.1.2. Theory of Operation 754 5.1.2.1. Originator RBridge 756 Identify the destination RBridge based on user specification or 757 based on location of the specified address (see below sections for 758 MAC discovery and address locator). 760 Construct the diagnostic payload based on user specified parameters. 761 Default parameters MUST be utilized for unspecified payload 762 parameters. See [TLICMPOAM] for default parameters. 764 Construct the TRILL OAM header. Set the opcode to (65), Loopback 765 message. Assign applicable identification number and sequence number 766 for the request. 768 TRILL OAM Version TLV MUST be included and set appropriate flags. 770 Construct following ICMP multipart extensions, where applicable 772 o Out-of-band response request 774 o Out-of-band IP address 776 o Diagnostic VLAN 778 Specify the Hop count of the TRILL data frame per user 779 specification. Or utilize the applicable Hop count value, if TRILL 780 TTL is not being specified. 782 Dispatch the diagnostic frame to the TRILL data plane for 783 transmission. 785 RBridge may continue to retransmit the request at periodic 786 intervals, until a response is received or the re-transmission count 787 expires. 789 5.1.2.2. Intermediate RBridge 791 Intermediate RBridges forward the frame as a normal data frame and 792 no special handling is required. 794 5.1.2.3. Destination RBridge 796 If the Loopback message is addressed to the local RBridge, then the 797 RBridge process the message. The implementation performs frame 798 validation and identifies OAM frames using methods specified in 799 section4.1.1. . The response is constructed as stated below. 801 Construction of the TRILL OAM response: 803 If out-of-band response is requested the destination IP address is 804 set to the IP address specified in the request message. Source IP 805 address is derived based on the outgoing IP interface address. UDP 806 destination port is the TRILL OAM UDP port number. 808 Implementations encode the received TRILL header and flow entropy in 809 the Original payload TLV. 811 If in-band response was requested, dispatch the frame to the TRILL 812 data plane with request-originator RBRidge nickname as the egress 813 RBridge nickname. 815 If out-of-band response was requested, dispatch the frame to the 816 standard IP forwarding process. 818 5.2. Loopback Message Hop-count method 820 The Loopback message procedures presented in [TLICMPOAM] Utilize 821 customers specified payload to derive the diagnostic payload 822 embedded in the OAM message. 824 From time to time, operators may desire the inclusion of actual user 825 packets as the flow entropy of the OAM frame. The Hop-count method 826 presented in this section facilitates inclusion of un-modified 827 payload. When unmodified payloads are included as the diagnostic 828 payload, there MUST be methods to identify such OAM frames from 829 regular data frames and there MUST be methods to prevent such OAM 830 frames from leaking out of TRILL network. Methods specified in 831 section 4.1.1. 4.1.1. allow RBridges to identify OAM frames. 833 5.2.1. Prevent leaking out from TRILL network 835 First, the ingress RBRidge that is generating the loopback message 836 MUST discover the TRILL hop count to the egress RBridge. The 837 discovered Hop count MUST be used as the hop count included in the 838 TRILL header. Further, if the specified payload is IP, the IP header 839 checksum SHOULD BE invalidated. The invalidation of IP checksum, 840 prevents end stations further processing the OAM frames, in the 841 unlikely event that it reached an end station due to a change in 842 topology because of which the hop count is unable to suppress the 843 message. 845 All other operations are similar to Loopback Message processing 846 presented in section 5.1.2. 848 6. Path Trace Message 850 Path Trace Message has the same format as Loopback Message. Opcode 851 for Path Trace Request Message is 66 and Response 67. 853 Please refer to [TLICMPOAM] for Theory of Operation and details of 854 Path Trace message. 856 7. Notification Messages 858 8. 860 TRILL OAM Notification message format is depicted in following 861 figure. 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Magic Number | Checksum | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | | 869 . TLVs . 870 | | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Figure 13 Notification OAM Message Format 875 The opcode of the Notification message is 68. Notification messages 876 may be generated for variety of errors, warning and informational 877 purposes. Notification messages are almost always asynchronous. 878 Hence there is no Session Identification. 880 TRILL OAM Version TLV, which is mandatory, MUST be the first TLV. 881 TRILL OAM Version TLV, has class field and code fields. 883 Class field specifies whether the message is Error, Warning or 884 Informational Notification message. Code Field within the class 885 specifies the actual notification. 887 9. Status Codes 889 Status codes are defined within a Class. Following Classes are 890 currently defined. 892 Success, Error, Warning, Informational. 894 There are no status codes defined within the success class. 896 9.1. Error Codes 898 Following Error codes are currently defined 900 1: Egress RBridge Nickname unknown 901 2: Hop Count Expired 902 3: VLAN Unknown 903 4: Parameter Problem 905 9.2. Warning Codes 907 TBD 909 9.3. Informational Codes 911 TBD 913 10. Security Considerations 915 TBD 917 11. Allocation Considerations 919 10.1 IEEE Allocation Considerations 921 The IEEE 802.1 Working Group is requested to allocate a separate 922 opcode and TLV space within 802.1g CFM messages for TRILL purpose. 924 10.2 IANA Considerations 926 - Set up sub-registry within the TRILL Parameters registry and 927 initial entries for block of TRILL OAM OpCodes - 929 - Set up sub-registry within the TRILL Parameters registry and 930 initial contents for TRILL OAM TLV Types - 932 12. References 934 12.1. Normative References 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, March 1997. 939 [8021ag] IEEE, "Virtual Bridged Local Area Networks Amendment 5: 940 Connectivity Fault Management", 802.1ag, 2007. 942 [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 943 Bridged Local Area Networks", IEEE Std 802.1Q-2011, 944 August 31st , 2011. 946 [TLICMPOAM] Senevirathne, T., et.al., "ICMP based OAM Solution for 947 TRILL", draft-tissa-trill-oam-03, Work in Progress, 948 January, 2012. 950 [FNV] Fowler, G., et.al., "The FNV Non-Cryptographic Hash 951 Algorithm", draft-eastlake-fnv-03, Work in Progress, 952 March, 2012. 954 12.2. Informative References 956 [RFC6325] Perlman, R., et.al., "Routing Bridges (RBridges): Base 957 Protocol Specification", RFC 6325, July 2011. 959 [TRILLML] Senevirathne, T., et.al., "Default Nickname Based Approach 960 for Multi-level TRILL", draft-tissa-trill-multilevel-00, 961 Work in Progress, February 2012. 963 13. Acknowledgments 965 Work in this document was largely inspired by the directions 966 provided by Stewart Bryant in finding common OAM solution between 967 SDO. 969 This document was prepared using 2-Word-v2.0.template.dot. 971 Authors' Addresses 973 Tissa Senevirathne 974 CISCO Systems 975 375 East Tasman Drive. 976 San Jose, CA 95134 977 USA. 979 Phone: +1 408-853-2291 980 Email: tsenevir@cisco.com 982 Samer Salam 983 CISCO Systems 984 595 Burrard St. Suite 2123 985 Vancouver, BC V7X 1J1, Canada 987 Email: ssalam@cisco.com 989 Donald Eastlake 990 Huawei Technologies 991 155 Beaver Street 992 Milford, MA 01757 994 Phone: +1-508-333-2270 995 Email: d3e3e3@gmail.com 997 Sam Aldrin 998 Huawei Technologies 999 2330 Central Express Way 1000 Santa Clara, CA 95951 1001 USA 1003 Email: aldrin.ietf@gmail.com 1004 Naveen Nimmu 1005 Broadcom 1006 9th Floor, Building no 9, Raheja Mind space 1007 Hi-Tec City, Madhapur, 1008 Hyderabad - 500 081, INDIA 1010 Phone: +1-408-218-8893 1011 Email: naveen@broadcom.com 1013 Tal Mizrahi 1014 Marvell 1015 6 Hamada St. 1016 Yokneam, 20692 Israel 1018 Email: talmi@marvell.com 1020 Anoop Ghanwani 1021 Dell 1022 300 Holger Way, 1023 San Jose, CA 95134, USA 1025 Phone: +1-408-571-3500 1026 Email: anoop@alumni.duke.edu.