idnits 2.17.1 draft-ietf-trill-loss-delay-08.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 == Line 1193 has weird spacing: '... value typ...' -- The document date (September 26, 2014) is 3492 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2679 (ref. 'IPPM-1DM') (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (ref. 'IPPM-Loss') (Obsoleted by RFC 7680) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Standards Track T. Senevirathne 4 Expires: March 2015 S. Salam 5 D. Kumar 6 Cisco 7 D. Eastlake 3rd 8 Huawei 9 September 26, 2014 11 Loss and Delay Measurement in 12 Transparent Interconnection of Lots of Links (TRILL) 13 15 Abstract 17 Performance Monitoring (PM) is a key aspect of Operations, 18 Administration, and Maintenance (OAM). It allows network operators to 19 verify the Service Level Agreement (SLA) provided to customers, and 20 to detect network anomalies. This document specifies mechanisms for 21 Loss Measurement and Delay Measurement in TRILL networks. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on March 26, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction ................................................. 3 64 2. Conventions Used in this Document ............................ 4 65 2.1. Keywords ................................................ 4 66 2.2. Definitions ............................................. 4 67 2.3. Abbreviations ........................................... 5 68 3. Loss and Delay Measurement in the TRILL Architecture ......... 6 69 3.1. Performance Monitoring Granularity ...................... 6 70 3.2. One-Way vs. Two-Way Performance Monitoring .............. 7 71 3.2.1. One-Way Performance Monitoring ..................... 7 72 3.2.2. Two-Way Performance Monitoring ..................... 7 73 3.3. Point-to-point vs. Point-to-multipoint PM ............... 8 74 4. Loss Measurement ............................................. 8 75 4.1. One-Way Loss Measurement ................................ 8 76 4.1.1. 1SL Message Transmission ........................... 9 77 4.1.2. 1SL Message Reception ............................. 10 78 4.2. Two-Way Loss Measurement ............................... 11 79 4.2.1. SLM Message Transmission .......................... 12 80 4.2.2. SLM Message Reception ............................. 12 81 4.2.3. SLR Message Reception ............................. 13 82 5. Delay Measurement ........................................... 14 83 5.1. One-Way Delay Measurement .............................. 14 84 5.1.1. 1DM Message Transmission .......................... 15 85 5.1.2. 1DM Message Reception ............................. 16 86 5.2. Two-Way Delay Measurement .............................. 16 87 5.2.1. DMM Message Transmission .......................... 17 88 5.2.2. DMM Message Reception ............................. 17 89 5.2.3. DMR Message Reception ............................. 18 90 6. Packet Formats .............................................. 19 91 6.1. TRILL OAM Encapsulation ................................ 19 92 6.2. Loss Measurement Packet Formats ........................ 21 93 6.2.1. Counter Format .................................... 21 94 6.2.2. 1SL Packet Format ................................. 21 95 6.2.3. SLM Packet Format ................................. 22 96 6.2.4. SLR Packet Format ................................. 23 97 6.3. Delay Measurement Packet Formats ....................... 24 98 6.3.1. Timestamp Format .................................. 24 99 6.3.2. 1DM Packet Format ................................. 24 100 6.3.3. DMM Packet Format ................................. 25 101 6.3.4. DMR Packet Format ................................. 27 102 6.4. OpCode Values .......................................... 28 103 7. Performance Monitoring Process .............................. 28 104 8. Security Considerations ..................................... 29 105 9. IANA Considerations ......................................... 30 106 10. Acknowledgments ............................................ 30 107 11. References ................................................. 30 108 11.1. Normative References .................................. 30 109 11.2. Informative References ................................ 31 111 1. Introduction 113 TRILL [RFCTRILL] is a protocol for transparent least cost routing, 114 where RBridges route traffic to their destination based on least 115 cost, using a TRILL encapsulation header with a hop count. 117 Operations, Administration, and Maintenance (OAM) [OAM] is a set of 118 tools for detecting, isolating and reporting connection failures and 119 performance degradation. Performance Monitoring (PM) is a key aspect 120 of OAM. PM allows network operators to detect and debug network 121 anomalies and incorrect behavior. PM consists of two main building 122 blocks - Loss Measurement and Delay Measurement. PM may also include 123 other derived metrics such as Packet Delivery Rate, and Inter-Frame 124 Delay Variation. 126 The requirements of OAM in TRILL networks are defined in [OAM-REQ], 127 and the TRILL OAM framework is described in [OAM-FRAMEWK]. These two 128 documents also highlight the main requirements in terms of 129 performance monitoring. 131 This document defines protocols for loss measurement and for delay 132 measurement in TRILL networks. These protocols are based on the 133 performance monitoring functionality defined in ITU-T G.8013/Y.1731 134 [Y.1731-2013]. 136 o Loss Measurement: the Loss Measurement protocol measures packet 137 loss between two RBridges. The measurement is performed by sending 138 a set of synthetic packets, and counting the number of packets 139 transmitted and received during the test. The frame loss is 140 calculated by comparing the numbers of transmitted and received 141 packets. This provides a statistical estimate of the packet loss 142 between the involved RBridges, with a margin of error that can be 143 controlled by varying the number of transmitted synthetic packets. 144 This document does not define procedures for packet loss 145 computation based on counting user data for the reasons given in 146 Section 5.1 of [OAM-FRAMEWK]. 148 o Delay Measurement: the Delay Measurement protocol measures the 149 packet delay and packet delay variation between two RBridges. The 150 measurement is performed using timestamped OAM messages. 152 2. Conventions Used in this Document 154 2.1. Keywords 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 [KEYWORDS]. 160 The requirement level of PM in [OAM-REQ] is 'SHOULD'. Nevertheless, 161 this memo uses the entire range of requirement levels, including 162 'MUST'; the requirements in this memo are to be read as 'A MEP 163 (Maintenance End Point) that implements TRILL PM 164 MUST/SHOULD/MAY/...'. 166 2.2. Definitions 168 o One-way packet delay - (based on [IPPM-1DM]) the time elapsed from 169 the start of transmission of the first bit of a packet by an 170 RBridge until the reception of the last bit of the packet by the 171 remote RBridge. 173 o Two-way packet delay - (based on [IPPM-2DM]) the time elapsed from 174 the start of transmission of the first bit of a packet from the 175 local RBridge, receipt of the packet at the remote RBridge, the 176 remote RBridge sending a response packet back to the local RBridge 177 and the local RBridge receiving the last bit of that response 178 packet. 180 o Packet loss - (based on [IPPM-Loss]) the number of packets sent by 181 a source RBridge and not received by the destination Rbridge. 182 In the context of this document, packet loss is measured at a 183 specific probe instance, and a specific observation period. 184 As in [Y.1731-2013], this document distinguishes between near-end 185 and far-end packet loss. Note that this semantic distinction 186 specifies the direction of packet loss, but does not affect the 187 nature of the packet loss metric, which is defined in [IPPM-Loss]. 189 o Far-end packet loss - the number of packets lost on the path from 190 the local RBridge to the remote RBridge in a specific probe 191 instance, and a specific observation period. 193 o Near-end packet loss - the number of packets lost on the path from 194 the remote RBridge to the local RBridge in a specific probe 195 instance, and a specific observation period. 197 2.3. Abbreviations 199 1DM One-way Delay Measurement message 201 1SL One-way Synthetic Loss Measurement message 203 DMM Delay Measurement Message 205 DMR Delay Measurement Reply 207 DoS Denial of Service 209 FGL Fine Grained Label [RFC-FGL] 211 MD Maintenance Domain 213 MD-L Maintenance Domain Level 215 MEP Maintenance End Point 217 MIP Maintenance Intermediate Point 219 MP Maintenance Point 221 OAM Operations, Administration, and Maintenance [OAM] 223 PM Performance Monitoring 225 SLM Synthetic Loss Measurement Message 226 SLR Synthetic Loss Measurement Reply 228 TLV Type, Length, and Value 230 TRILL Transparent Interconnection of Lots of Links [RFCTRILL] 232 3. Loss and Delay Measurement in the TRILL Architecture 234 As described in [OAM-FRAMEWK], OAM protocols in a TRILL campus 235 operate over two types of Maintenance Points (MPs): Maintenance End 236 Points (MEPs) and Maintenance Intermediate Points (MIPs). 238 +-------+ +-------+ +-------+ 239 | | | | | | 240 | RB1 |<===>| RB3 |<===>| RB2 | 241 | | | | | | 242 +-------+ +-------+ +-------+ 243 MEP MIP MEP 245 Figure 1 Maintenance Points in a TRILL Campus 247 Performance Monitoring (PM) allows a MEP to perform loss and delay 248 measurements to any other MEP in the campus. Performance Monitoring 249 is performed in the context of a specific Maintenance Domain (MD). 251 The PM functionality defined in this document is not applicable to 252 MIPs. 254 3.1. Performance Monitoring Granularity 256 As defined in [OAM-FRAMEWK], PM can be applied at three levels of 257 granularity: 'Network', 'Service' and 'Flow'. 259 o Network-level PM: the PM protocol is run over a dedicated test 260 VLAN or FGL [RFC-FGL]. 262 o Service-level PM: the PM protocol is used to perform measurements 263 of actual user VLANs or FGL. 265 o Flow-level PM: the PM protocol is used to perform measurements on 266 a per-flow basis. A flow, as defined in [OAM-REQ], is a set of 267 packets that share the same path and per-hop behavior (such as 268 priority). As defined in [OAM-FRAMEWK], flow-based monitoring uses 269 a Flow Entropy field that resides at the beginning of the OAM 270 packet header (see Section 6.1.), and mimics the forwarding 271 behavior of the monitored flow. 273 3.2. One-Way vs. Two-Way Performance Monitoring 275 Paths in a TRILL network are not necessarily symmetric, that is, a 276 packet sent from RB1 to RB2 does not necessarily traverse the same 277 set of RBridges or links as a packet sent from RB2 to RB1. Even 278 within a given flow, packets from RB1 to RB2 do not necessarily 279 traverse the same path as packets from RB2 to RB1. 281 3.2.1. One-Way Performance Monitoring 283 In one-way PM, RB1 sends PM messages to RB2, allowing RB2 to monitor 284 the performance on the path from RB1 to RB2. 286 A MEP that implements TRILL PM SHOULD support one-way performance 287 monitoring. A MEP that implements TRILL PM SHOULD support both the PM 288 functionality of the sender, RB1, and the PM functionality of the 289 receiver, RB2. 291 One-way PM can be applied either proactively or on-demand, although 292 the more typical scenario is the proactive mode, where RB1 and RB2 293 periodically transmit PM messages to each other, allowing each of 294 them to monitor the performance on the incoming path from the peer 295 MEP. 297 3.2.2. Two-Way Performance Monitoring 299 In two-way PM, a sender, RB1, sends PM messages to a reflector, RB2, 300 and RB2 responds to these messages, allowing RB1 to monitor the 301 performance of: 303 o The path from RB1 to RB2. 305 o The path from RB2 to RB1. 307 o The two-way path from RB1 to RB2, and back to RB1. 309 Note that in some cases it may be interesting for RB1 to monitor only 310 the path from RB1 to RB2. Two-way PM allows the sender, RB1, to 311 monitor the path from RB1 to RB2, as opposed to one-way PM (Section 312 3.2.1.), which allows the receiver, RB2, to monitor this path. 314 A MEP that implements TRILL PM MUST support two-way PM. A MEP that 315 implements TRILL PM MUST support both the sender and the reflector PM 316 functionality. 318 As described in Section 3.1. , flow-based PM uses the Flow Entropy 319 field as one of the parameters that identify a flow. In two-way PM, 320 the Flow Entropy of the path from RB1 to RB2 is typically different 321 from the Flow Entropy of the path from RB2 to RB1. This document uses 322 the Reflector Entropy TLV [TRILL-FM], which allows the sender to 323 specify the Flow Entropy value to be used in the response message. 325 Two-way PM can be applied either proactively or on-demand. 327 3.3. Point-to-point vs. Point-to-multipoint PM 329 PM can be applied either as a point-to-point measurement protocol, or 330 as a point-to-multi-point measurement protocol. 332 The point-to-point approach measures the performance between two 333 RBridges using unicast PM messages. 335 In the point-to-multipoint approach, an RBridge RB1 sends PM messages 336 to multiple RBridges using multicast messages. The reflectors (in 337 two-way PM) respond to RB1 using unicast messages. To protect against 338 reply storms, the reflectors MUST send the response messages after a 339 random delay in the range of 0 to 2 seconds. This ensures that the 340 responses are staggered in time, and that the initiating RBridge is 341 not overwhelmed with responses. Moreover, a scope TLV [TRILL-FM] can 342 be used to limit the set of RBridges from which a response is 343 expected, thus reducing the impact of potential response bursts. 345 4. Loss Measurement 347 The Loss Measurement protocol has two flavors, one-way Loss 348 Measurement, and two-way Loss Measurement. 350 Note: The terms 'one-way' and 'two-way' Loss Measurement should not 351 be confused with the terms 'single-ended' and 'dual-ended' Loss 352 Measurement used in [Y.1731-2013]. As defined in Section 3.2. , the 353 terms 'one-way' and 'two-way' specify whether the protocol monitors 354 performance on one direction, or on both directions. The terms 355 'single-ended' and 'dual-ended', on the other hand, describe whether 356 the protocol is asymmetric or symmetric, respectively. 358 4.1. One-Way Loss Measurement 360 One-way Loss Measurement measures the one-way packet loss from one 361 MEP to another. The loss ratio is measured using a set of One-way 362 Synthetic Loss Measurement (1SL) messages. The packet format of the 363 1SL message is specified in Section 6.2.2. Figure 2 illustrates a 364 one-way Loss Measurement message exchange. 366 TXp TXc 367 Sender -------------------------------------- 368 \ \ 369 \ 1SL . . . \ 1SL 370 \ \ 371 \/ \/ 372 Receiver -------------------------------------- 373 RXp RXc 375 Figure 2 One-Way Loss Measurement 377 The one-way Loss Measurement procedure uses a set of 1SL messages to 378 measure the packet loss. The figure shows two non-consecutive 379 messages from the set. 381 The sender maintains a counter of transmitted 1SL messages, and 382 includes the value of this counter, TX, in each 1SL message it 383 transmits. The receiver maintains a counter of received 1SL messages, 384 RX, and can calculate the loss by comparing its counter values to the 385 counter values received in the 1SL messages. 387 In Figure 2, the subscript 'c' is an abbreviation for current, and 388 'p' is an abbreviation for previous. 390 4.1.1. 1SL Message Transmission 392 One-way Loss Measurement can be applied either proactively or on- 393 demand, although as mentioned in Section 3.2.1. , it is more likely 394 to be applied proactively. 396 The term 'on-demand' in the context of one-way Loss Measurement 397 implies that the sender transmits a fixed set of 1SL messages, 398 allowing the receiver to perform the measurement based on this set. 400 A MEP that supports one-way Loss Measurement MUST support unicast 401 transmission of 1SL messages. 403 A MEP that supports one-way Loss Measurement MAY support multicast 404 transmission of 1SL messages. 406 The sender MUST maintain a packet counter for each peer MEP and probe 407 instance (test ID). Every time the sender transmits a 1SL packet, it 408 increments the corresponding counter, and then integrates the value 409 of the counter into the field of the 1SL packet. 411 The 1SL message MAY be sent with a variable size Data TLV, allowing 412 loss measurement for various packet sizes. 414 4.1.2. 1SL Message Reception 416 The receiver MUST maintain a reception counter for each peer MEP and 417 probe instance (test ID). Upon receiving a 1SL packet, the receiver 418 MUST verify that: 420 o The 1SL packet is destined to the current MEP. 422 o The packet's MD level matches the MEP's MD level. 424 If both conditions are satisfied, the receiver increments the 425 corresponding receive packet counter, and records the new value of 426 the counter, RX1. 428 A MEP that supports one-way Loss Measurement MUST support reception 429 of both unicast and multicast 1SL messages. 431 The receiver computes the one-way packet loss with respect to a probe 432 instance measurement interval. A probe instance measurement interval 433 includes a sequence of 1SL messages with the same test ID. The one- 434 way packet loss is computed by comparing the counter values TXp and 435 RXp at the beginning of the measurement interval, and the counter 436 values TXc and RXc at the end of the measurement interval (Figure 2): 438 one-way packet loss = (TXc-TXp) - (RXc-RXp) (1) 440 The calculation in Equation (1) is based on counter value 441 differences, implying that the sender's counter, TX, and the 442 receiver's counter, RX, are not required to be synchronized with 443 respect to a common initial value. 445 It is noted that if the sender or receiver resets one of the 446 counters, TX or RX, the calculation in Equation (1) produces a false 447 measurement result. Hence the sender and receiver SHOULD NOT clear 448 the TX and RX counters during a measurement interval. 450 When the receiver calculates the packet loss per Equation (1) it MUST 451 perform a wraparound check. If the receiver detects that one of the 452 counters has wrapped around, the receiver adjusts the result of 453 Equation (1) accordingly. 455 A 1SL receiver MUST support reception of 1SL messages with a Data 456 TLV. 458 Since synthetic one-way Loss Measurement is performed using 1SL 459 messages, obviously some 1SL messages may be dropped during a 460 measurement interval. Thus, when the receiver does not receive a 1SL, 461 the receiver cannot perform the calculations in Equation (1) for that 462 specific 1SL message. 464 4.2. Two-Way Loss Measurement 466 Two-way Loss Measurement allows a MEP to measure the packet loss on 467 the paths to and from a peer MEP. Two-way Loss Measurement uses a set 468 of Synthetic loss Measurement Messages (SLM) to compute the packet 469 loss. Each SLM is answered with a Synthetic loss Measurement Reply 470 (SLR). The packet formats of the SLM and SLR packets are specified in 471 Sections 6.2.3. and 6.2.4. , respectively. Figure 2 illustrates a 472 two-way Loss Measurement message exchange. 474 TXp RXp TXc RXc 475 Sender ----------------------------------------------- 476 \ /\ \ /\ 477 \ / . . . \ / 478 SLM \ / SLR SLM \ / SLR 479 \/ / \/ / 480 Reflector ----------------------------------------------- 481 TRXp TRXc 483 Figure 3 Two-Way Loss Measurement 485 The two-way Loss Measurement procedure uses a set of SLM-SLR 486 handshakes. The figure shows two non-consecutive handshakes from the 487 set. 489 The sender maintains a counter of transmitted SLM messages, and 490 includes the value of this counter, TX, in each transmitted SLM 491 message. The reflector maintains a counter of received SLM messages, 492 TRX. The reflector generates an SLR, and incorporates TRX into the 493 SLR packet. The sender maintains a counter of received SLR messages, 494 RX. Upon receiving an SLR message, the sender can calculate the loss 495 by comparing the local counter values to the counter values received 496 in the SLR messages. 498 The subscript 'c' is an abbreviation for current, and 'p' is an 499 abbreviation for previous. 501 4.2.1. SLM Message Transmission 503 Two-way Loss Measurement can be applied either proactively or on- 504 demand. 506 A MEP that supports two-way Loss Measurement MUST support unicast 507 transmission of SLM messages. 509 A MEP that supports two-way Loss Measurement MAY support multicast 510 transmission of SLM messages. 512 The sender MUST maintain a counter of transmitted SLM packets for 513 each peer MEP and probe instance (test ID). Every time the sender 514 transmits an SLM packet it increments the corresponding counter, and 515 then integrates the value of the counter into the field 516 of the SLM packet. 518 A sender MAY include a Reflector Entropy TLV in an SLM message. The 519 Reflector Entropy TLV format is specified in [TRILL-FM]. 521 An SLM message MAY be sent with a Data TLV, allowing loss measurement 522 for various packet sizes. 524 4.2.2. SLM Message Reception 526 The reflector MUST maintain a reception counter, TRX, for each peer 527 MEP and probe instance (test ID). 529 Upon receiving an SLM packet, the reflector MUST verify that: 531 o The SLM packet is destined to the current MEP. 533 o The packet's MD level matches the MEP's MD level. 535 If both conditions are satisfied, the reflector increments the 536 corresponding packet counter, and records the value of the new 537 counter, TRX. The reflector then generates an SLR message that is 538 identical to the received SLM, except for the following 539 modifications: 541 o The reflector incorporates TRX into the field of the 542 SLR. 544 o The field in the OAM header is set to the SLR OpCode. 546 o The reflector assigns its MEP ID in the field. 548 o If the received SLM includes a Reflector Entropy TLV [TRILL-FM], 549 the reflector copies the value of the Flow Entropy from the TLV 550 into the field of the SLR message. The outgoing SLR 551 message does not include a Reflector Entropy TLV. 553 o The TRILL header and transport header are modified to reflect the 554 source and destination of the SLR packet. The SLR is always a 555 unicast message. 557 A MEP that supports two-way Loss Measurement MUST support reception 558 of both unicast and multicast SLM messages. 560 A reflector MUST support reception of SLM packets with a Data TLV. 561 When receiving an SLM with a Data TLV, the reflector includes the 562 unmodified TLV in the SLR. 564 4.2.3. SLR Message Reception 566 The sender MUST maintain a reception counter, RX, for each peer MEP 567 and probe instance (test ID). 569 Upon receiving an SLR message, the sender MUST verify that: 571 o The SLR packet is destined to the current MEP. 573 o The field in the SLR packet matches the current 574 MEP. 576 o The packet's MD level matches the MEP's MD level. 578 If the conditions above are met, the sender increments the 579 corresponding reception counter, and records the new value, RX. 581 The sender computes the packet loss with respect to a probe instance 582 measurement interval. A probe instance measurement interval includes 583 a sequence of SLM messages, and their corresponding SLR messages, all 584 with the same test ID. The packet loss is computed by comparing the 585 counters at the beginning of the measurement interval, denoted with a 586 subscript 'p', and the counters at the end of the measurement 587 interval, denoted with a subscript 'c' (as illustrated in Figure 3). 589 far-end packet loss = (TXc-TXp) - (TRXc-TRXp) (2) 591 near-end packet loss = (TRXc-TRXp) - (RXc-RXp) (3) 593 Note: total two-way packet loss is the sum of the far and near end 594 packet losses, that is (TXc-TXp) - (RXc-RXp). 596 The calculations in the two equations above are based on counter 597 value differences, implying that the sender's counters, TX and RX, 598 and the reflector's counter, TRX, are not required to be synchronized 599 with respect to a common initial value. 601 It is noted that if the sender or reflector resets one of the 602 counters, TX, TRX or RX, the calculation in Equations (2) and (3) 603 produces a false measurement result. Hence the sender and reflector 604 SHOULD NOT clear the TX, TRX and RX counters during a measurement 605 interval. 607 When the sender calculates the packet loss per Equations (2) and (3) 608 it MUST perform a wraparound check. If the reflector detects that one 609 of the counters has wrapped around, the reflector adjusts the result 610 of Equations (2) and (3) accordingly. 612 Since synthetic two-way Loss Measurement is performed using SLM and 613 SLR messages, obviously some SLM and SLR messages may be dropped 614 during a measurement interval. When an SLM or an SLR is dropped, the 615 corresponding two-way handshake (Figure 3) is not completed 616 successfully, and thus the reflector does not perform the 617 calculations in Equations (2) and (3) for that specific message 618 exchange. 620 A sender MAY choose to monitor only the far-end packet loss, that is, 621 perform the computation in Equation (2), and ignore the computation 622 in Equation (3). Note that, in this case, the sender can run flow- 623 based PM of the path TO the peer MEP without using the Reflector 624 Entropy TLV. 626 5. Delay Measurement 628 The Delay Measurement protocol has two flavors, One-Way Delay 629 Measurement, and Two-Way Delay Measurement. 631 5.1. One-Way Delay Measurement 633 One-way Delay Measurement is used for computing the one-way packet 634 delay from one MEP to another. The packet format used in one-way 635 Delay Measurement is referred to as 1DM, and is specified in Section 636 6.3.2. The one-way Delay Measurement message exchange is illustrated 637 in Figure 4. 639 T1 640 Sender ------------------- ----> time 641 \ 642 \ 1DM 643 \ 644 \/ 645 Receiver ------------------- 646 T2 648 Figure 4 One-Way Delay Measurement 650 The sender transmits a 1DM message incorporating its time of 651 transmission, T1. The receiver then receives the message at time T2, 652 and calculates the one-way delay as: 654 one-way delay = T2-T1 (4) 656 Equation (4) implies that T2 and T1 are measured with respect to a 657 common reference time. Hence, two MEPs running an one-way Delay 658 Measurement protocol MUST be time-synchronized. The method used for 659 synchronizing the clocks associated with the two MEPs is outside the 660 scope of this document. 662 5.1.1. 1DM Message Transmission 664 1DM packets can be transmitted proactively or on-demand, although as 665 mentioned in Section 3.2.1. , they are typically transmitted 666 proactively. 668 A MEP that supports one-way Delay Measurement MUST support unicast 669 transmission of 1DM messages. 671 A MEP that supports one-way Delay Measurement MAY support multicast 672 transmission of 1DM messages. 674 A 1DM message MAY be sent with a variable size Data TLV, allowing 675 packet delay measurement for various packet sizes. 677 The sender incorporates the 1DM packet's time of transmission into 678 the field. 680 5.1.2. 1DM Message Reception 682 Upon receiving a 1DM packet, the receiver records its time of 683 reception, T2. The receiver MUST verify two conditions: 685 o The 1DM packet is destined to the current MEP. 687 o The packet's MD level matches the MEP's MD level. 689 If both conditions are satisfied, the receiver terminates the packet 690 and calculates the one-way delay as specified in Equation (4). 692 A MEP that supports one-way Delay Measurement MUST support reception 693 of both unicast and multicast 1DM messages. 695 A 1DM receiver MUST support reception of 1DM messages with a Data 696 TLV. 698 When one-way Delay Measurement packets are received periodically, the 699 receiver MAY compute the packet delay variation based on multiple 700 measurements. Note that packet delay variation can be computed even 701 when the two peer MEPs are not time synchronized. 703 5.2. Two-Way Delay Measurement 705 Two-way Delay Measurement uses a two-way handshake for computing the 706 two-way packet delay between two MEPs. The handshake includes two 707 packets, a Delay Measurement Message (DMM) and a Delay Measurement 708 Reply (DMR). The DMM and DMR packet formats are specified in Section 709 6.3.3. and 6.3.4. , respectively. 711 The two-way Delay Measurement message exchange is illustrated in 712 Figure 5. 714 T1 T4 715 Sender ----------------------- ----> time 716 \ /\ 717 \ / 718 DMM \ / DMR 719 \/ / 720 Reflector ----------------------- 721 T2 T3 723 Figure 5 Two-Way Delay Measurement 725 The sender generates a DMM message incorporating its time of 726 transmission, T1. The reflector receives the DMM message and records 727 its time of reception, T2. The reflector then generates a DMR 728 message, incorporating T1, T2 and the DMR's transmission time, T3. 729 The sender receives the DMR message at T4, and using the 4 timestamps 730 it calculates the two-way packet delay. 732 5.2.1. DMM Message Transmission 734 DMM packets can be transmitted periodically or on-demand. 736 A MEP that supports two-way Delay Measurement MUST support unicast 737 transmission of DMM messages. 739 A MEP that supports two-way Delay Measurement MAY support multicast 740 transmission of DMM messages. 742 A sender MAY include a Reflector Entropy TLV in a DMM message. The 743 Reflector Entropy TLV format is specified in [TRILL-FM]. 745 A DMM MAY be sent with a variable size Data TLV, allowing packet 746 delay measurement for various packet sizes. 748 The sender incorporates the DMM packet's time of transmission into 749 the field. 751 5.2.2. DMM Message Reception 753 Upon receiving a DMM packet, the reflector records its time of 754 reception, T2. The reflector MUST verify two conditions: 756 o The DMM packet is destined to the current MEP. 758 o The packet's MD level matches the MEP's MD level. 760 If both conditions are satisfied, the reflector terminates the 761 packet, and generates a DMR packet. The DMR is identical to the 762 received DMM, except for the following modifications: 764 o The reflector incorporates T2 into the field of the 765 DMR. 767 o The reflector incorporates the DMR's transmission time, T3, into 768 the field of the DMR. 770 o The field in the OAM header is set to the DMR OpCode. 772 o If the received DMM includes a Reflector Entropy TLV [TRILL-FM], 773 the reflector copies the value of the Flow Entropy from the TLV 774 into the field of the DMR message. The outgoing DMR 775 message does not include a Reflector Entropy TLV. 777 o The TRILL header and transport header are modified to reflect the 778 source and destination of the DMR packet. The DMR is always a 779 unicast message. 781 A MEP that supports two-way Delay Measurement MUST support reception 782 of both unicast and multicast DMM messages. 784 A reflector MUST support reception of DMM packets with a Data TLV. 785 When receiving a DMM with a Data TLV, the reflector includes the 786 unmodified TLV in the DMR. 788 5.2.3. DMR Message Reception 790 Upon receiving the DMR message, the sender records its time of 791 reception, T4. The sender MUST verify: 793 o The DMR packet is destined to the current MEP. 795 o The packet's MD level matches the MEP's MD level. 797 If both conditions above are met, the sender uses the 4 timestamps to 798 compute the two-way delay: 800 two-way delay = (T4-T1) - (T3-T2) (5) 802 Note that two-way delay can be computed even when the two peer MEPs 803 are not time synchronized. One-way Delay Measurement, on the other 804 hand, requires the two MEPs to be synchronized. 806 Two MEPs running a two-way Delay Measurement protocol MAY be time- 807 synchronized. If two-way Delay Measurement is run between two time- 808 synchronized MEPs, the sender MAY compute the one-way delays: 810 one-way delay {sender->reflector} = T2 - T1 (6) 812 one-way delay {reflector->sender} = T4 - T3 (7) 814 When two-way Delay Measurement is run periodically, the sender MAY 815 also compute the delay variation based on multiple measurements. 817 A sender MAY choose to monitor only the sender->reflector delay, that 818 is, perform the computation in Equation (6), and ignore the 819 computations in (5) and (7). Note that in this case the sender can 820 run flow-based PM of the path to the peer MEP without using the 821 Reflector Entropy TLV. 823 6. Packet Formats 825 6.1. TRILL OAM Encapsulation 827 The TRILL OAM packet format is generally discussed in [OAM-FRAMEWK], 828 and specified in detail in [TRILL-FM]. It is quoted in this document 829 for convenience. 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | 833 . Link Header . (variable) 834 | | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | | 837 + TRILL Header + 6 or more bytes 838 | | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | | 841 . Flow Entropy . 96 bytes 842 . . 843 | | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | OAM Ether Type | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | | 848 . OAM Message Channel . Variable 849 . . 850 | | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Link Trailer | Variable 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Figure 6 TRILL OAM Encapsulation 857 The OAM Message Channel used in this document is defined in [TRILL- 858 FM], and has the following structure: 860 0 1 2 3 861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 |MD-L | Version | OpCode | Flags |FirstTLVOffset | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | | 866 . OpCode-specific fields . 867 | | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | | 870 . TLVs . 871 | | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Figure 7 OAM Packet Format 875 The first 4 octets of the OAM Message Channel are common to all 876 OpCodes, whereas the rest is OpCode-specific. Below is a brief 877 summary of the fields in the first 4 octets: 879 o MD-L : Maintenance Domain Level. 881 o Version: indicates the version of this protocol. Always zero in 882 the context of this document. 884 o OpCode: Operation Code (8 bits). Specifies the operation performed 885 by the message. See specific packet formats later in this 886 document. 888 o Flags: The definition of flags is OpCode-specific. The value of 889 this field is zero unless otherwise stated. 891 o FirstTLVOffset: defines the location of the first TLV, in octets, 892 starting from the end of the FirstTLVOffset field. 894 o TLVs: one or more TLV fields. The last TLV field is always an End 895 TLV. 897 For further details about the OAM packet format, including the format 898 of TLVs, see [TRILL-FM]. 900 6.2. Loss Measurement Packet Formats 902 6.2.1. Counter Format 904 Loss Measurement packets use a 32-bit packet counter field. When a 905 counter is incremented beyond its maximal value, 0xFFFFFFFF, it wraps 906 around back to 0. 908 6.2.2. 1SL Packet Format 910 0 1 2 3 911 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 |MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Sender MEP ID | Reserved (0) | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Test ID | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Counter TX | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Reserved (0) | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | | 924 . TLVs . 925 | | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 Figure 8 1SL Packet Format 929 For fields not listed below, see Section 6.1. 931 o OpCode: see Section 6.4. 933 o FirstTLVOffset: defines the location of the first TLV, in octets, 934 starting from the end of the FirstTLVOffset field. The value of 935 this field MUST be 16 in 1SL packets. 937 o Sender MEP ID: the MEP ID of the MEP that initiated the 1SL. 939 o Reserved (0): set to 0 by the sender and ignored by the receiver. 941 o Test ID: a 32-bit unique test identifier. 943 o Counter TX: the value of the sender's transmission counter, 944 including this packet, at the time of transmission. 946 6.2.3. SLM Packet Format 948 0 1 2 3 949 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 |MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | Sender MEP ID | Reserved for Reflector MEP ID | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Test ID | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Counter TX | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Reserved for SLR: Counter TRX (0) | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | | 962 . TLVs . 963 | | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Figure 9 SLM Packet Format 967 For fields not listed below, see Section 6.1. 969 o OpCode: see Section 6.4. 971 o FirstTLVOffset: defines the location of the first TLV, in octets, 972 starting from the end of the FirstTLVOffset field. The value of 973 this field MUST be 16 in SLM packets. 975 o Sender MEP ID: the MEP ID of the MEP that initiated this packet. 977 o Reserved for Reflector MEP ID: this field is reserved for the 978 reflector's MEP ID, to be added in the SLR. 980 o Test ID: a 32-bit unique test identifier. 982 o Counter TX: the value of the sender's transmission counter, 983 including this packet, at the time of transmission. 985 o Reserved for SLR: this field is reserved for the SLR corresponding 986 to this packet. The reflector uses this field in the SLR for 987 carrying TRX, the value of its reception counter. 989 6.2.4. SLR Packet Format 991 0 1 2 3 992 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |MD-L | Ver (0) | OpCode | Flags (0) |FirstTLVOffset | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Sender MEP ID | Reflector MEP ID | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Test ID | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Counter TX | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Counter TRX | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | | 1005 . TLVs . 1006 | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 Figure 10 SLR Packet Format 1010 For fields not listed below, see Section 6.1. 1012 o OpCode: see Section 6.4. 1014 o FirstTLVOffset: defines the location of the first TLV, in octets, 1015 starting from the end of the FirstTLVOffset field. The value of 1016 this field MUST be 16 in SLR packets. 1018 o Sender MEP ID: the MEP ID of the MEP that initiated the SLM that 1019 this SLR replies to. 1021 o Reflector MEP ID: the MEP ID of the MEP that transmits this SLR 1022 message. 1024 o Test ID: a 32-bit unique test identifier, copied from the 1025 corresponding SLM message. 1027 o Counter TX: the value of the sender's transmission counter at the 1028 time of the SLM transmission. 1030 o Counter TRX: the value of the reflector's reception counter, 1031 including this packet, at the time of reception of the 1032 corresponding SLM packet. 1034 6.3. Delay Measurement Packet Formats 1036 6.3.1. Timestamp Format 1038 The timestamps used in Delay Measurement packets are 64 bits long. 1039 These timestamps use the 64 least significant bits of the IEEE 1588- 1040 2008 (1588v2) Precision Time Protocol timestamp format [IEEE1588]. 1042 This truncated format consists of a 32-bit seconds field followed by 1043 a 32-bit nanoseconds field. This truncated format is also used in 1044 IEEE 1588v1, in [Y.1731-2013], and in [MPLS-LM-DM]. 1046 6.3.2. 1DM Packet Format 1048 0 1 2 3 1049 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 |MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Timestamp T1 | 1054 | | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Reserved for 1DM receiving equipment (0) | 1057 | (for Timestamp T2) | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | | 1060 . TLVs . 1061 | | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 Figure 11 1DM Packet Format 1065 For fields not listed below, see Section 6.1. 1067 o OpCode: see Section 6.4. 1069 o Reserved (0): Upper part of Flags field. Set to 0 by the sender 1070 and ignored by the receiver. 1072 o T: Type flag. When this flag is set it indicates proactive 1073 operation, and when cleared it indicates on-demand mode. 1075 o FirstTLVOffset: defines the location of the first TLV, in octets, 1076 starting from the end of the FirstTLVOffset field. The value of 1077 this field MUST be 16 in 1DM packets. 1079 o Timestamp T1: specifies the time of transmission of this packet. 1081 o Reserved for 1DM: this field is reserved for internal usage of the 1082 1DM receiver. The receiver can use this field for carrying T2, the 1083 time of reception of this packet. 1085 6.3.3. DMM Packet Format 1087 0 1 2 3 1088 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 |MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Timestamp T1 | 1093 | | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Reserved for DMM receiving equipment (0) | 1096 | (for Timestamp T2) | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Reserved for DMR (0) | 1099 | (for Timestamp T3) | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Reserved for DMR receiving equipment | 1102 | | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | | 1105 . TLVs . 1106 | | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 Figure 12 DMM Packet Format 1110 For fields not listed below, see Section 6.1. 1112 o OpCode: see Section 6.4. 1114 o Reserved (0): Upper part of Flags field. Set to 0 by the sender 1115 and ignored by the receiver. 1117 o T: Type flag. When this flag is set it indicates proactive 1118 operation, and when cleared it indicates on-demand mode. 1120 o FirstTLVOffset: defines the location of the first TLV, in octets, 1121 starting from the end of the FirstTLVOffset field. The value of 1122 this field MUST be 32 in DMM packets. 1124 o Timestamp T1: specifies the time of transmission of this packet. 1126 o Reserved for DMM: this field is reserved for internal usage of the 1127 MEP that receives the DMM (the reflector). The reflector can use 1128 this field for carrying T2, the time of reception of this packet. 1130 o Reserved for DMR: two timestamp fields are reserved for the DMR 1131 message. One timestamp field is reserved for T3, the DMR 1132 transmission time, and the other field is reserved for internal 1133 usage of the MEP that receives the DMR. 1135 6.3.4. DMR Packet Format 1137 0 1 2 3 1138 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 |MD-L | Ver (1) | OpCode | Reserved (0)|T|FirstTLVOffset | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Timestamp T1 | 1143 | | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Timestamp T2 | 1146 | | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Timestamp T3 | 1149 | | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Reserved for DMR receiving equipment | 1152 | (for Timestamp T4) | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | | 1155 . TLVs . 1156 | | 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 Figure 13 DMR Packet Format 1160 For fields not listed below, see Section 6.1. 1162 o OpCode: see Section 6.4. 1164 o Reserved (0): Upper part of Flags field. Set to 0 by the sender 1165 and ignored by the receiver. 1167 o T: Type flag. When this flag is set it indicates proactive 1168 operation, and when cleared it indicates on-demand mode. 1170 o FirstTLVOffset: defines the location of the first TLV, in octets, 1171 starting from the end of the FirstTLVOffset field. The value of 1172 this field MUST be 32 in DMR packets. 1174 o Timestamp T1: specifies the time of transmission of the DMM packet 1175 that this DMR replies to. 1177 o Timestamp T2: specifies the time of reception of the DMM packet 1178 that this DMR replies to. 1180 o Timestamp T3: specifies the time of transmission of this DMR 1181 packet. 1183 o Reserved for DMR: this field is reserved for internal usage of the 1184 MEP that receives the DMR (the sender). The sender can use this 1185 field for carrying T4, the time of reception of this packet. 1187 6.4. OpCode Values 1189 As the OAM packets specified herein conform to [Y.1731-2013], the 1190 same OpCodes are used as follows: 1192 OpCode OAM packet 1193 value type 1194 ------ ---------- 1196 45 1DM 1198 46 DMR 1200 47 DMM 1202 53 1SL 1204 54 SLR 1206 55 SLM 1208 These OpCodes are from the range of values that has been allocated by 1209 IEEE 802.1 [802.1Q] for control by ITU-T. 1211 7. Performance Monitoring Process 1213 The Performance Monitoring process is made up of a number of 1214 Performance Monitoring instances, known as PM Sessions. A PM session 1215 can be initiated between two MEPs on a specific flow and be defined 1216 as either a Loss Measurement session or Delay Measurement session. 1218 The Loss Measurement session can be used to determine the performance 1219 metrics Frame Loss Ratio, availability, and resiliency. The Delay 1220 Measurement session can be used to determine the performance metrics 1221 Frame Delay, Inter-Frame Delay Variation, Frame Delay Range, and Mean 1222 Frame Delay. 1224 The PM session is defined by the specific PM function (PM tool) being 1225 run, and also by the Start Time, Stop time, Message Period, 1226 Measurement Interval, and Repetition Time. These terms are defined as 1227 follows: 1229 o The Start Time is the time that the PM session begins. 1231 o The Stop Time is the time that the measurement ends. 1233 o The Message Period is the message transmission frequency (the time 1234 between message transmissions). 1236 o The Measurement Interval is the time period over which 1237 measurements are gathered and then summarized. The Measurement 1238 Interval can align with the PM Session duration, but it doesn't 1239 need to. PM messages are only transmitted during a PM Session. 1241 o The Repetition Time is the time between start times of the 1242 Measurement Intervals. 1244 Measurement Interval Measurement Interval 1245 (Completed, Historic) (In Process, Current) 1246 | | 1247 | | 1248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 ^ ^ ^ ^ 1251 | | | | 1252 Start time Message Stop time 1253 (service enabled) Period (Service disabled) 1255 Figure 14 Relationship Between Different Timing Parameters 1257 8. Security Considerations 1259 The security considerations of TRILL OAM are discussed in [OAM-REQ] 1260 and in [OAM-FRAMEWK] and in [TRILL-FM]. General TRILL security 1261 considerations are discussed in [RFCTRILL]. 1263 As discussed in [OAM-Over], an attack on a PM protocol can falsely 1264 indicate nonexistent performance issues, or prevent the detection of 1265 actual ones, consequently resulting in DoS (Denial of Service). 1266 Furthermore, synthetic PM messages can be used maliciously as a means 1267 to implement DoS attacks on RBridges. Another security aspect is 1268 network reconnaissance; by passively eavesdropping to PM messages an 1269 attacker can gather information that can be used maliciously to 1270 attack the network. 1272 As in [TRILL-FM], TRILL PM OAM Messages MAY include the OAM 1273 Authentication TLV. It should be noted that an Authentication TLV 1274 requires a cryptographic algorithm, which may have performance 1275 implications on the RBridges that take part in the protocol, and thus 1276 may, in some cases, affect the measurement results. Based on a 1277 system-specific threat assessment, the benefits of the security TLV 1278 must be weighed against the potential measurement inaccuracy it may 1279 inflict, and based on this tradeoff operators should take a decision 1280 whether to use authentication. 1282 9. IANA Considerations 1284 This document requires no IANA actions. RFC Editor: Please delete 1285 this section before publication. 1287 10. Acknowledgments 1289 The authors gratefully acknowledge Adrian Farrel, Alexey Melnikov, 1290 Jan Novak, Carlos Pignataro, Gagan Mohan Goel, Pete Resnick, and 1291 Prabhu Raj for their helpful comments. 1293 This document was prepared using 2-Word-v2.0.template.dot. 1295 11. References 1297 11.1. Normative References 1299 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1300 Requirement Levels", BCP 14, RFC 2119, March 1997. 1302 [RFCTRILL] Perlman, R., Eastlake, D., Dutt, D., Gai, S., 1303 Ghanwani, A., "Routing Bridges (RBridges): Base 1304 Protocol Specification", RFC 6325, July 2011. 1306 [RFC-FGL] D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. 1307 Dutt," Transparent Interconnection of Lots of Links 1308 (TRILL): Fine-Grained Labeling", RFC 7172, May 2014. 1310 [TRILL-FM] Senevirathne, T., Finn, N., Salam, S., Kumar, D., 1311 Eastlake, D., Aldrin, S., Li, Y., "TRILL Fault 1312 Management", draft-ietf-trill-oam-fm (work in 1313 progress), April 2014. 1315 11.2. Informative References 1317 [OAM-REQ] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve, 1318 R., "Requirements for Operations, Administration and 1319 Maintenance (OAM) in Transparent Interconnection of 1320 Lots of Links (TRILL)", RFC 6905, March 2013. 1322 [OAM-FRAMEWK] Salam, S., Senevirathne, T., Aldrin, S., Eastlake, D., 1323 "Transparent Interconnection of Lots of Links (TRILL) 1324 Operations, Administration, and Maintenance (OAM) 1325 Framework", RFC 7174, May 2014. 1327 [Y.1731-2013] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and 1328 Mechanisms for Ethernet-based Networks", July 2011. 1330 [802.1Q] "IEEE Standard for Local and metropolitan area 1331 networks - Media Access Control (MAC) Bridges and 1332 Virtual Bridged Local Area Networks", IEEE Std 1333 802.1Q(tm), 2012 Edition, October 2012. 1335 [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, 1336 "1588 IEEE Standard for a Precision Clock 1337 Synchronization Protocol for Networked Measurement and 1338 Control Systems Version 2", IEEE Standard, 2008. 1340 [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay 1341 Measurement for MPLS Networks", RFC 6374, September 1342 2011. 1344 [OAM] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, 1345 D., Mansfield, S., "Guidelines for the use of the OAM 1346 acronym in the IETF ", RFC 6291, June 2011. 1348 [IPPM-1DM] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 1349 Delay Metric for IPPM", RFC 2679, September 1999. 1351 [IPPM-2DM] Almes, G., Kalidindi, S. and M. Zekauskas, "A round- 1352 trip delay metric for IPPM", RFC 2681, September 1999. 1354 [IPPM-Loss] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 1355 Packet Loss Metric for IPPM", RFC 2680, September 1356 1999. 1358 [OAM-Over] Mizrahi, T., Sprecher, N., Bellagamba, E. and Y. 1359 Weingarten, "An Overview of Operations, 1360 Administration, and Maintenance (OAM) Tools", RFC 1361 7276, June 2014. 1363 Authors' Addresses 1365 Tal Mizrahi 1366 Marvell 1367 6 Hamada St. 1368 Yokneam, 20692 Israel 1370 Email: talmi@marvell.com 1372 Tissa Senevirathne 1373 Cisco 1374 375 East Tasman Drive 1375 San Jose, CA 95134, USA 1377 Email: tsenevir@cisco.com 1379 Samer Salam 1380 Cisco 1381 595 Burrard Street, Suite 2123 1382 Vancouver, BC V7X 1J1, Canada 1384 Email: ssalam@cisco.com 1386 Deepak Kumar 1387 Cisco 1388 510 McCarthy Blvd, 1389 Milpitas, CA 95035, USA 1391 Phone : +1 408-853-9760 1392 Email: dekumar@cisco.com 1394 Donald Eastlake 3rd 1395 Huawei Technologies 1396 155 Beaver Street 1397 Milford, MA 01757 USA 1399 Phone: +1-508-333-2270 1400 Email: d3e3e3@gmail.com