[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-trill-loss-delay

TRILL Working Group                                           T. Mizrahi
Internet Draft                                                   Marvell
Intended status: Standards Track                         T. Senevirathne
Expires: January 2014                                           S. Salam
                                                                D. Kumar
                                                                   Cisco
                                                         D. Eastlake 3rd
                                                                  Huawei
                                                           July 14, 2013

                       Loss and Delay Measurement in
            Transparent Interconnection of Lots of Links (TRILL)
                   draft-mizrahi-trill-loss-delay-01.txt


Abstract

   Performance Monitoring (PM) is a key aspect of Operations,
   Administration and Maintenance (OAM). It allows network operators to
   verify the Service Level Agreement (SLA) provided to customers, and
   to detect network anomalies. This document specifies mechanisms for
   Loss Measurement (LM) and Delay Measurement (DM) in TRILL networks.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 14, 2014.






Mizrahi, et al.       Expires January 14, 2014                [Page 1]


Internet-Draft      TRILL Performance Monitoring             July 2013


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction ................................................. 3
   2. Conventions Used in this Document ............................ 4
      2.1. Keywords ................................................ 4
      2.2. Definitions ............................................. 4
      2.3. Abbreviations ........................................... 5
   3. Loss and Delay Measurement in the TRILL Architecture ......... 6
      3.1. Performance Monitoring Granularity ...................... 6
      3.2. One-Way vs. Two-Way Performance Monitoring .............. 7
         3.2.1. One-Way Performance Monitoring ..................... 7
         3.2.2. Two-Way Performance Monitoring ..................... 7
      3.3. Point-to-point PM vs. Point-to-multipoint PM ............ 8
   4. Loss Measurement ............................................. 8
      4.1. One-Way Loss Measurement (OWLM) ......................... 9
         4.1.1. 1SL Message Transmission ........................... 9
         4.1.2. 1SL Message Reception ............................. 10
      4.2. Two-Way Loss Measurement (TWLM) ........................ 11
         4.2.1. SLM Message Transmission .......................... 12
         4.2.2. SLM Message Reception ............................. 12
         4.2.3. SLR Message Reception ............................. 13
   5. Delay Measurement ........................................... 14
      5.1. One-Way Delay Measurement (OWDM) ....................... 14
         5.1.1. 1DM Message Transmission .......................... 15
         5.1.2. 1DM Message Reception ............................. 15
      5.2. Two-Way Delay Measurement (TWDM) ....................... 16
         5.2.1. DMM Message Transmission .......................... 16
         5.2.2. DMM Message Reception ............................. 17
         5.2.3. DMR Message Reception ............................. 17
   6. Packet Formats .............................................. 18
      6.1. TRILL OAM Encapsulation ................................ 18
      6.2. Loss Measurement Packet Formats ........................ 20


Mizrahi, et al.       Expires January 14, 2014                [Page 2]


Internet-Draft      TRILL Performance Monitoring             July 2013


         6.2.1. Counter Format .................................... 20
         6.2.2. 1SL Packet Format ................................. 21
         6.2.3. SLM Packet Format ................................. 22
         6.2.4. SLR Packet Format ................................. 23
      6.3. Delay Measurement Packet Formats ....................... 24
         6.3.1. Timestamp Format .................................. 24
         6.3.2. 1DM Packet Format ................................. 24
         6.3.3. DMM Packet Format ................................. 25
         6.3.4. DMR Packet Format ................................. 26
   7. Security Considerations ..................................... 27
   8. Performance Monitoring Process .............................. 27
      8.1. LM Statistics .......................................... 28
      8.2. DM Statistics .......................................... 29
   9. IANA Considerations ......................................... 32
      9.1. OpCode Values .......................................... 32
   10. Acknowledgments ............................................ 32
   11. References ................................................. 32
      11.1. Normative References .................................. 32
      11.2. Informative References ................................ 33


1. Introduction

   TRILL [RFCTRILL] is a protocol for transparent least cost routing,
   where RBridges forward traffic to their destination based on a least
   cost route, using a TRILL encapsulation header with a hop count.

   Operations, Administration and Maintenance (OAM) [OAM] is a set of
   tools for detecting, isolating and reporting connection failures and
   performance degradation. Performance Monitoring (PM) is a key aspect
   of OAM. PM allows network operators to detect and debug network
   anomalies and incorrect behavior. PM consists of two main building
   blocks - Loss Measurement (LM) and Delay Measurement (DM). PM may
   also include other derived metrics such as Packet Delivery Rate
   (PDR), and Inter-Frame Delay Variation (IFDV).

   The requirements of OAM in TRILL networks are defined in [OAM-REQ],
   and the TRILL OAM framework is described in [OAM-FRAMEWK]. These two
   documents also highlight the main requirements in terms of
   performance monitoring.

   This document defines protocols for loss measurement and for delay
   measurement in TRILL networks. These protocols are somewhat based on
   the mechanisms defined in ITU-T G.8013/Y.1731 [Y.1731].





Mizrahi, et al.       Expires January 14, 2014                [Page 3]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o Loss Measurement (LM): the LM protocol measures packet loss
      between two RBridges. The measurement is performed by sending a
      set of synthetic packets, and counting the number of packets
      transmitted and received during the test. The loss rate is
      calculated by comparing the numbers of transmitted and received
      packets.
      This provides a statistical estimate of the packet loss between
      the involved RBridges, with a margin of error that can be
      controlled by varying the number of transmitted synthetic packets.
      This document does not define procedures for packet loss
      computation based on counting user data. For further details see
      [OAM-FRAMEWK].

   o Delay Measurement (DM): the DM protocol measures the packet delay
      and packet delay variation between two RBridges. The measurement
      is performed using timestamped OAM messages.

2. Conventions Used in this Document

2.1. Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

   The requirement level of PM in [OAM-REQ] is 'SHOULD'. Nevertheless,
   this memo uses the entire range of requirement levels, including
   'MUST'; the requirements in this memo are to be read as 'A MEP that
   implements TRILL PM MUST/SHOULD/MAY/...'.

2.2. Definitions

   o One-way packet delay - (as defined in [OAM-REQ]) the time elapsed
      from the start of transmission of the first bit of a packet by an
      RBridge until the reception of the last bit of the packet by the
      remote RBridge.

   o Two-way packet delay - (as defined in [OAM-REQ]) the time elapsed
      from the start of transmission of the first bit of a packet from
      the local RBridge, receipt of the packet at the remote RBridge,
      the remote RBridge sending a response packet back to the local
      RBridge and the local RBridge receiving the last bit of that
      response packet.

   o Packet loss - the number of packets lost in a specific probe
      instance, and a specific observation period.



Mizrahi, et al.       Expires January 14, 2014                [Page 4]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o Far-end packet loss - the number of packets lost on the path from
      the local RBridge to the remote RBridge in a specific probe
      instance, and a specific observation period.

   o Near-end packet loss - the number of packets lost on the path from
      the remote RBridge to the local RBridge in a specific probe
      instance, and a specific observation period.

2.3. Abbreviations

   1DM      One-way Delay Measurement message

   1LM      One-way Loss Measurement message

   DM       Delay Measurement

   DMM      Delay Measurement Message

   DMR      Delay Measurement Reply

   FD       Frame Delay

   FDR      Frame Delay Range

   FLR      Frame Loss Ratio

   IFDV     Inter-Frame Delay Variation

   MD       Maintenance Domain

   MD-L     Maintenance Domain Level

   MEP      Maintenance End Point

   MFD      Mean Frame Delay

   MIP      Maintenance Intermediate Point

   MP       Maintenance Point

   LM       Loss Measurement

   OAM      Operations, Administration and Maintenance

   OWDM     One-Way Delay Measurement

   OWLM     One-Way Loss Measurement


Mizrahi, et al.       Expires January 14, 2014                [Page 5]


Internet-Draft      TRILL Performance Monitoring             July 2013


   PDR      Packet Delivery Rate

   PM       Performance Monitoring

   TLV      Type, Length and Value

   TRILL    Transparent Interconnection of Lots of Links

   TWDM     Two-Way Delay Measurement

   TWLM     Two-Way Loss Measurement

3. Loss and Delay Measurement in the TRILL Architecture

   As described in [OAM-FRAMEWK], OAM protocols in a TRILL campus
   operate over two types of Maintenance Points (MPs): Maintenance End
   Points (MEPs) and Maintenance Intermediate Points (MIPs).

                 +-------+     +-------+     +-------+
                 |       |     |       |     |       |
                 |  RB1  |<===>|  RB3  |<===>|  RB2  |
                 |       |     |       |     |       |
                 +-------+     +-------+     +-------+
                    MEP           MIP           MEP

               Figure 1 Maintenance Points in a TRILL Campus

   Performance Monitoring (PM) allows a MEP to perform loss and delay
   measurements to any other MEP in the campus. Performance Monitoring
   is performed in the context of a specific Maintenance Domain (MD).

   The PM functionality defined in this document is not applicable to
   MIPs.

3.1. Performance Monitoring Granularity

   As defined in [OAM-FRAMEWK], PM can be applied at three levels of
   granularity: 'Network', 'Service' and 'Flow'.

   o Network-level PM: the PM protocol is run over a dedicated test
      VLAN or FGL.

   o Service-level PM: the PM protocol is used to perform measurements
      of actual user VLANs or FGL.




Mizrahi, et al.       Expires January 14, 2014                [Page 6]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o Flow-level PM: the PM protocol is used to perform measurements on
      a per-flow basis. A flow, as defined in [OAM-REQ], is a set of
      packets that share the same path and per-hop behavior (such as
      priority).
      As defined in [OAM-FRAMEWK], flow-based monitoring uses a Flow
      Entropy field that resides at the beginning of the OAM packet
      header (see Section 6.1.), and mimics the forwarding behavior of
      the monitored flow.

3.2. One-Way vs. Two-Way Performance Monitoring

   Paths in a TRILL network are not necessarily symmetric, i.e., a
   packet sent from RB1 to RB2 does not necessarily traverse the same
   set of RBridges or links as a packet sent from RB2 to RB1. Even
   within a given flow, packets from RB1 to RB2 do not necessarily
   traverse the same path as packets from RB2 to RB1. Therefore, this
   document provides tools for one-way performance monitoring and for
   two-way performance monitoring.

3.2.1. One-Way Performance Monitoring

   In one-way PM, RB1 sends PM messages to RB2, allowing RB2 to monitor
   the performance on the path from RB1 to RB2.

   A MEP that implements TRILL PM SHOULD support one-way performance
   monitoring. A MEP that implements TRILL PM SHOULD support both the
   functionality of the sender, RB1, and the functionality of the
   receiver, RB2.

   One-way PM can be applied either proactively or on-demand, although
   the more typical scenario is the proactive mode, where RB1 and RB2
   periodically transmit PM messages to each other, allowing each of
   them to monitor the performance on the incoming path from the peer
   MEP.

3.2.2. Two-Way Performance Monitoring

   In two-way PM, a sender, RB1, sends PM messages to a reflector, RB2,
   and RB2 responds to these messages, allowing RB1 to monitor the
   performance of:

   o The path from RB1 to RB2.

   o The path from RB2 to RB1.

   o The two-way path from RB1 to RB2, and back to RB1.



Mizrahi, et al.       Expires January 14, 2014                [Page 7]


Internet-Draft      TRILL Performance Monitoring             July 2013


   Note that in some cases it may be interesting for RB1 to monitor only
   the path from RB1 to RB2. Two-way PM allows the sender, RB1, to
   monitor the path from RB1 to RB2, as opposed to one-way PM (Section
   3.2.1.), which allows the receiver, RB2, to monitor this path.

   A MEP that implements TRILL PM MUST support two-way PM. A MEP that
   implements TRILL PM MUST support both the sender and the reflector
   functionality.

   As described in Section 3.1. , flow-based PM uses the Flow Entropy
   field as one of the parameters that identify a flow. In two-way PM,
   the Flow Entropy of the path from RB1 to RB2 is typically different
   from the Flow Entropy of the path from RB2 to RB1. This document uses
   the Reflector Entropy TLV [TRILL-FM],), which allows the sender to
   specify the Flow Entropy value to be used in the response message.

   Two-way PM can be applied either proactively or on-demand.

3.3. Point-to-point PM vs. Point-to-multipoint PM

   PM can be applied either as a point-to-point measurement protocol, or
   as a point-to-multi-point measurement protocol.

   The point-to-point approach measures the performance between two
   RBridges using unicast PM messages.

   In the point-to-multipoint approach, an RBridge RB1 sends PM messages
   to multiple RBridges using multicast messages. The reflectors (in
   two-way PM) respond to RB1 using unicast messages. To protect against
   reply storms, the reflectors MUST send the response messages after a
   random delay in the range of 0 to 2 seconds. This ensures that the
   responses are staggered in time, and that the initiating RBridge is
   not overwhelmed with responses.

4. Loss Measurement

   The LM protocol has two flavors, One-Way Loss Measurement (OWLM), and
   Two-Way Loss Measurement (TWLM).

   Notes: [Y.1731] defines two-way LM, but does not support one-way LM.
   The terms 'one-way' and 'two-way' LM should not be confused with the
   terms 'single-ended' and 'dual-ended' LM used in [Y.1731]. As defined
   in Section 3.2. , the terms 'one-way' and 'two-way' specify whether
   the protocol monitors performance on one direction, or on both
   directions. The terms 'single-ended' and 'dual-ended', on the other
   hand, describe whether the protocol is asymmetric or symmetric,
   respectively.


Mizrahi, et al.       Expires January 14, 2014                [Page 8]


Internet-Draft      TRILL Performance Monitoring             July 2013


4.1. One-Way Loss Measurement (OWLM)

   OWLM measures the one-way packet loss rate from one MEP to another.
   The loss rate is measured using a set of One-way Synthetic Loss
   Measurement (1SL) messages. The packet format of the 1SL message is
   specified in Section 6.2.2. Figure 2 illustrates an OWLM message
   exchange.

                        TXp              TXc
          Sender    --------------------------------------
                          \                \
                           \ 1SL   . . .    \ 1SL
                            \                \
                            \/               \/
          Receiver  --------------------------------------
                            RXp              RXc

                     Figure 2 One-Way Loss Measurement



   The OWLM procedure uses a set of 1SL messages to measure the packet
   loss rate. The figure shows two non-consecutive messages from the
   set.

   The sender maintains a counter of transmitted 1SL messages, and
   includes the value of this counter, TX, in each 1SL message it
   transmits. The receiver maintains a counter of received 1SL messages,
   RX, and can calculate the loss rate by comparing its counter values
   to the counter values received in the 1SL messages.

   In Figure 2, the subscript 'c' is short for current, and 'p' is short
   for previous.

4.1.1. 1SL Message Transmission

   OWLM can be applied either proactively or on-demand, although as
   mentioned in Section 3.2.1. , it is more likely to be applied
   proactively.

   The term 'on-demand' in the context of OWLM implies that the sender
   transmits a fixed set of 1SL messages, allowing the receiver to
   perform the measurement based on this set.




Mizrahi, et al.       Expires January 14, 2014                [Page 9]


Internet-Draft      TRILL Performance Monitoring             July 2013


   A MEP that supports OWLM MUST support unicast transmission of 1SL
   messages.

   A MEP that supports OWLM MAY support multicast transmission of 1SL
   messages.

   The sender MUST maintain a packet counter for each peer MEP and probe
   instance (test ID). Every time the sender transmits a 1SL packet, it
   increments the corresponding counter, and then integrates the value
   of the counter into the <Counter TX> field of the 1SL packet.
   Therefore, the first packet of a probe instance is sent with the
   counter value set to 1.

   The 1SL message MAY be sent with a variable size Data TLV, allowing
   loss measurement for various packet sizes.

4.1.2. 1SL Message Reception

   The receiver MUST maintain a reception counter for each peer MEP and
   probe instance (test ID). Upon receiving a 1SL packet, the receiver
   MUST verify that:

   o The 1SL packet is destined to the current MEP.

   o The packet's MD level matches the MEP's MD level.

   If both conditions are satisfied, the receiver increments the
   corresponding receive packet counter, and records the new value of
   the counter, RX1.

   A MEP that supports OWLM MUST support reception of both unicast and
   multicast 1SL messages.

   The receiver computes the one-way packet loss with respect to a probe
   instance measurement interval. A probe instance measurement interval
   includes a sequence of 1SL messages with the same test ID. The one-
   way packet loss is computed by comparing the counter values TXp and
   RXp at the beginning of the measurement interval, and the counter
   values TXc and RXc at the end of the measurement interval (Figure 2):

           one-way packet loss = (TXc-TXp) - (RXc-RXp)     (1)

   The calculation in Equation (1) is based on counter value
   differences, implying that the sender's counter, TX, and the
   receiver's counter, RX, are not required to be synchronized with
   respect to a common initial value.



Mizrahi, et al.       Expires January 14, 2014               [Page 10]


Internet-Draft      TRILL Performance Monitoring             July 2013


   When the receiver calculates the packet loss per Equation (1) it MUST
   perform a wraparound check. If the receiver detects that one of the
   counters has wrapped around, the receiver adjusts the result of
   Equation (1) accordingly.

   A 1SL receiver MUST support reception of 1SL messages with a Data
   TLV.

4.2. Two-Way Loss Measurement (TWLM)

   TWLM allows a MEP to measure the packet loss on the paths to and from
   a peer MEP. TWLM uses a set of Synthetic loss Measurement Messages
   (SLM) to compute the packet loss. Each SLM is answered with a
   Synthetic loss Measurement Reply (SLR). The packet formats of the SLM
   and SLR packets are specified in Sections 6.2.3. and 6.2.4. ,
   respectively. Figure 2 illustrates a TWLM message exchange.





                   TXp       RXp             TXc       RXc
     Sender     -----------------------------------------------
                     \       /\                \       /\
                      \      /      . . .       \      /
                   SLM \    / SLR            SLM \    / SLR
                       \/  /                     \/  /
     Reflector  -----------------------------------------------
                        TRXp                      TRXc

                     Figure 3 Two-Way Loss Measurement



   The TWLM procedure uses a set of SLM-SLR handshakes. The figure shows
   two non-consecutive handshakes from the set.

   The sender maintains a counter of transmitted SLM messages, and
   includes the value of this counter, TX, in each transmitted SLM
   message. The reflector maintains a counter of received SLM messages,
   TRX. The reflector generates an SLR, and incorporates TRX into the
   SLR packet. The sender maintains a counter of received SLR messages,
   RX. Upon receiving an SLR message, the sender can calculate the loss
   rate by comparing the local counter values to the counter values
   received in the SLR messages.


Mizrahi, et al.       Expires January 14, 2014               [Page 11]


Internet-Draft      TRILL Performance Monitoring             July 2013


   The subscript 'c' is short for current, and 'p' is short for
   previous.

4.2.1. SLM Message Transmission

   TWLM can be applied either proactively or on-demand.

   A MEP that supports TWLM MUST support unicast transmission of SLM
   messages.

   A MEP that supports TWLM MAY support multicast transmission of SLM
   messages.

   The sender MUST maintain a counter of transmitted SLM packets for
   each peer MEP and probe instance (test ID). Every time the sender
   transmits an SLM packet it increments the corresponding counter, and
   then integrates the value of the counter into the <Counter TX> field
   of the SLM packet. Therefore, the first packet of a probe instance is
   sent with the counter value set to 1.

   A sender MAY include a Reflector Entropy TLV in an SLM message. The
   Reflector Entropy TLV format is specified in [TRILL-FM].

   An SLM message MAY be sent with a Data TLV, allowing loss measurement
   for various packet sizes.

4.2.2. SLM Message Reception

   The reflector MUST maintain a reception counter, TRX, for each peer
   MEP and probe instance (test ID).

   Upon receiving an SLM packet, the reflector MUST verify that:

   o The SLM packet is destined to the current MEP.

   o The packet's MD level matches the MEP's MD level.

   If both conditions are satisfied, the reflector increments the
   corresponding packet counter, and records the value of the new
   counter, TRX. The reflector then generates an SLR message that is
   identical to the received SLM, except for the following
   modifications:

   o The reflector incorporates TRX into the <Counter TRX> field of the
      SLR.

   o The <OpCode> field in the OAM header is set to the SLR OpCode.


Mizrahi, et al.       Expires January 14, 2014               [Page 12]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o The reflector assigns its MEP ID in the <Reflector MEP ID> field.

   o If the received SLM includes a Reflector Entropy TLV [TRILL-FM],
      the reflector copies the value of the Flow Entropy from the TLV
      into the <Flow Entropy> field of the SLR message. The outgoing SLR
      message does not include a Reflector Entropy TLV.

   o The TRILL header and transport header are modified to reflect the
      source and destination of the SLR packet. The SLR is always a
      unicast message.

   A MEP that supports TWLM MUST support reception of both unicast and
   multicast SLM messages.

   A reflector MUST support reception of SLM packets with a Data TLV.
   When receiving an SLM with a Data TLV, the reflector includes the
   unmodified TLV in the SLR.

4.2.3. SLR Message Reception

   The sender MUST maintain a reception counter, RX, for each peer MEP
   and probe instance (test ID).

   Upon receiving an SLR message, the sender MUST verify that:

   o The SLR packet is destined to the current MEP.

   o The <Sender MEP ID> field in the SLR packet matches the current
      MEP.

   o The packet's MD level matches the MEP's MD level.

   If the conditions above are met, the sender increments the
   corresponding reception counter, and records the new value, RX.

   The sender computes the packet loss with respect to a probe instance
   measurement interval. A probe instance measurement interval includes
   a sequence of SLM messages, and their corresponding SLR messages, all
   with the same test ID. The packet loss rate is computed by comparing
   the counters at the beginning of the measurement interval, denoted
   with a subscript 'p', and the counters at the end of the measurement
   interval, denoted with a subscript 'c' (as illustrated in Figure 3).

         far-end packet loss = (TXc-TXp) - (TRXc-TRXp)     (2)

         near-end packet loss = (TRXc-TRXp) - (RXc-RXp)     (3)



Mizrahi, et al.       Expires January 14, 2014               [Page 13]


Internet-Draft      TRILL Performance Monitoring             July 2013


   The calculations in the two equations above are based on counter
   value differences, implying that the sender's counters, TX and RX,
   and the reflector's counter, TRX, are not required to be synchronized
   with respect to a common initial value.

   When the sender calculates the packet loss per Equations (2) and (3)
   it MUST perform a wraparound check. If the reflector detects that one
   of the counters has wrapped around, the reflector adjusts the result
   of Equations (2) and (3) accordingly.

   A sender MAY choose to monitor only the far-end packet loss, i.e.,
   perform the computation in Equation (2), and ignore the computation
   in Equation (3). Note that, in this case, the sender can run flow-
   based PM of the path TO the peer MEP without using the Reflector
   Entropy TLV.

5. Delay Measurement

   The DM protocol has two flavors, One-Way Delay Measurement (OWDM),
   and Two-Way Delay Measurement (TWDM).

5.1. One-Way Delay Measurement (OWDM)

   OWDM is used for computing the one-way packet delay from one MEP to
   another. The packet format used in OWDM is referred to as 1DM, and is
   specified in Section 6.3.2. The OWDM message exchange is illustrated
   in Figure 4.

                                     T1
                      Sender    -------------------         ----> time
                                      \
                                       \ 1DM
                                        \
                                        \/
                      Receiver  -------------------
                                        T2

                    Figure 4 One-Way Delay Measurement



   The sender transmits a 1DM message incorporating its time of
   transmission, T1. The receiver then receives the message at time T2,
   and calculates the one-way delay as:



Mizrahi, et al.       Expires January 14, 2014               [Page 14]


Internet-Draft      TRILL Performance Monitoring             July 2013


                         one-way delay = T2-T1       (4)

   Equation (4) implies that T2 and T1 are measured with respect to a
   common reference time. Hence, two MEPs running an OWDM protocol MUST
   be time-synchronized. The method used for synchronizing the clocks
   associated with the two MEPs is outside the scope of this document.

5.1.1. 1DM Message Transmission

   1DM packets can be transmitted proactively or on-demand, although as
   mentioned in Section 3.2.1. , they are typically transmitted
   proactively.

   A MEP that supports OWDM MUST support unicast transmission of 1DM
   messages.

   A MEP that supports OWDM MAY support multicast transmission of 1DM
   messages.

   A 1DM message MAY be sent with a variable size Data TLV, allowing
   packet delay measurement for various packet sizes.

   The sender incorporates the 1DM packet's time of transmission into
   the <Timestamp T1> field.

5.1.2. 1DM Message Reception

   Upon receiving a 1DM packet, the receiver records its time of
   reception, T2. The receiver MUST verify two conditions:

   o The 1DM packet is destined to the current MEP.

   o The packet's MD level matches the MEP's MD level.

   If both conditions are satisfied, the receiver terminates the packet
   and calculates the one-way delay as specified in Equation (4).

   A MEP that supports OWDM MUST support reception of both unicast and
   multicast 1DM messages.

   A 1DM receiver MUST support reception of 1DM messages with a Data
   TLV.

   When OWDM packets are received periodically, the receiver MAY compute
   the packet delay variation based on multiple measurements. Note that
   packet delay variation can be computed even when the two peer MEPs
   are not time synchronized.


Mizrahi, et al.       Expires January 14, 2014               [Page 15]


Internet-Draft      TRILL Performance Monitoring             July 2013


5.2. Two-Way Delay Measurement (TWDM)

   TWDM uses a two-way handshake for computing the two-way packet delay
   between two MEPs. The handshake includes two packets, a Delay
   Measurement Message (DMM) and a Delay Measurement Reply (DMR). The
   DMM and DMR packet formats are specified in Section 6.3.3. and 6.3.4.
   , respectively.

   The TWDM message exchange is illustrated in Figure 5.

                                   T1          T4
                    Sender     -----------------------       ----> time
                                    \          /\
                                     \         /
                                  DMM \       / DMR
                                      \/     /
                    Reflector  -----------------------
                                      T2    T3

                    Figure 5 Two-Way Delay Measurement



   The sender generates a DMM message incorporating its time of
   transmission, T1. The reflector receives the DMM message and records
   its time of reception, T2. The reflector then generates a DMR
   message, incorporating T1, T2 and the DMR's transmission time, T3.
   The sender receives the DMR message at T4, and using the 4 timestamps
   it calculates the two-way packet delay.

5.2.1. DMM Message Transmission

   DMM packets can be transmitted periodically or on-demand.

   A MEP that supports TWDM MUST support unicast transmission of DMM
   messages.

   A MEP that supports TWDM MAY support multicast transmission of DMM
   messages.

   A sender MAY include a Reflector Entropy TLV in a DMM message. The
   Reflector Entropy TLV format is specified in [TRILL-FM].

   A DMM MAY be sent with a variable size Data TLV, allowing packet
   delay measurement for various packet sizes.


Mizrahi, et al.       Expires January 14, 2014               [Page 16]


Internet-Draft      TRILL Performance Monitoring             July 2013


   The sender incorporates the DMM packet's time of transmission into
   the <Timestamp T1> field.

5.2.2. DMM Message Reception

   Upon receiving a DMM packet, the reflector records its time of
   reception, T2. The reflector MUST verify two conditions:

   o The DMM packet is destined to the current MEP.

   o The packet's MD level matches the MEP's MD level.

   If both conditions are satisfied, the reflector terminates the
   packet, and generates a DMR packet. The DMR is identical to the
   received DMM, except for the following modifications:

   o The reflector incorporates T2 into the <Timestamp T2> field of the
      DMR.

   o The reflector incorporates the DMR's transmission time, T3, into
      the <Timestamp T3> field of the DMR.

   o The <OpCode> field in the OAM header is set to the DMR OpCode.

   o If the received DMM includes a Reflector Entropy TLV [TRILL-FM],
      the reflector copies the value of the Flow Entropy from the TLV
      into the <Flow Entropy> field of the DMR message. The outgoing DMR
      message does not include a Reflector Entropy TLV.

   o The TRILL header and transport header are modified to reflect the
      source and destination of the DMR packet. The DMR is always a
      unicast message.

   A MEP that supports TWDM MUST support reception of both unicast and
   multicast DMM messages.

   A reflector MUST support reception of DMM packets with a Data TLV.
   When receiving a DMM with a Data TLV, the reflector includes the
   unmodified TLV in the DMR.

5.2.3. DMR Message Reception

   Upon receiving the DMR message, the sender records its time of
   reception, T4. The sender MUST verify:

   o The DMR packet is destined to the current MEP.



Mizrahi, et al.       Expires January 14, 2014               [Page 17]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o The packet's MD level matches the MEP's MD level.

   If both conditions above are met, the sender uses the 4 timestamps to
   compute the two-way delay:

                   two-way delay = (T4-T1) - (T3-T2)       (5)

   While OWDM requires the two MEPs to be synchronized, TWDM allows the
   sender to calculate the two-way delay without being synchronized to
   the reflector.

   Two MEPs running a TWDM protocol MAY be time-synchronized. If TWDM is
   run between two time-synchronized MEPs, the sender MAY compute the
   one-way delays:

              one-way delay {sender->reflector} = T2 - T1       (6)

              one-way delay {reflector->sender} = T4 - T3       (7)

   When TWDM is run periodically, the sender MAY also compute the delay
   variation based on multiple measurements.

   A sender MAY choose to monitor only the sender->reflector delay,
   i.e., perform the computation in Equation (6), and ignore the
   computations in (5) and (7). Note that in this case the sender can
   run flow-based PM of the path TO the peer MEP without using the
   Reflector Entropy TLV.

6. Packet Formats

6.1. TRILL OAM Encapsulation

   The TRILL OAM encapsulation is defined in [OAM-FRAMEWK], and is
   quoted in this document for clarity. For further details see [OAM-
   FRAMEWK].













Mizrahi, et al.       Expires January 14, 2014               [Page 18]


Internet-Draft      TRILL Performance Monitoring             July 2013


        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        .      Link Header              . Variable
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               | 8 bytes
        +      TRILL Header             + fixed part of TRILL Header
        |                               | _
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |  \
        |   DA   /   SA             |   |   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |   |
        |   Data Label              |   |    \  Flow Entropy
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    /  Fixed Size
        .                               .   |
        .                               .   |
        |                               | _/
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       OAM EtherType           | 2 bytes
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        .   OAM Message Channel         . Variable
        .                               .
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                               |
        .    Link Trailer               . Variable
        |                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 6 TRILL OAM Encapsulation



   The OAM Message Channel used in this document is defined in [TRILL-
   FM], and has the following structure:










Mizrahi, et al.       Expires January 14, 2014               [Page 19]


Internet-Draft      TRILL Performance Monitoring             July 2013


       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Version | OpCode        |  Flags        |TLVOffset      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         OpCode-specific fields                                .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 7 OAM Packet Format

   The first 4 octets of the OAM Message Channel are common to all
   OpCodes, whereas the rest is OpCode-specific. Below is a brief
   summary of the fields in the first 4 octets:

   o MD-L : Maintenance Domain Level.

   o Version: indicates the version of this protocol. Always zero in
      the context of this document.

   o Flags: always zero in the context of this document.

   o FirstTLVOffset: defines the location of the first TLV, in octets,
      starting from the end of the FirstTLVOffset field.

   For further details about the OAM packet format, see [TRILL-FM].

6.2. Loss Measurement Packet Formats

6.2.1. Counter Format

   LM packets use a 32-bit packet counter field. When a counter is
   incremented beyond its maximal value, 0xFFFFFFFF, it wraps around
   back to 0.









Mizrahi, et al.       Expires January 14, 2014               [Page 20]


Internet-Draft      TRILL Performance Monitoring             July 2013


6.2.2. 1SL Packet Format

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Ver (0) | OpCode        |  Flags (0)    |TLVOffset (16) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Sender MEP ID          |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Test ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Counter TX                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 8 1SL Packet Format





   o Sender MEP ID: the MEP ID of the MEP that initiated the 1SL.

   o Reserved: always 0.

   o Test ID: a 32-bit unique test identifier.

   o Counter TX: the value of the sender's transmission counter,
      including this packet, at the time of transmission.













Mizrahi, et al.       Expires January 14, 2014               [Page 21]


Internet-Draft      TRILL Performance Monitoring             July 2013


6.2.3. SLM Packet Format

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Ver (0) | OpCode        |  Flags (0)    |TLVOffset (16) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Sender MEP ID          | Reserved for Reflector MEP ID |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Test ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Counter TX                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Reserved for SLR: Counter TRX (0)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 9 SLM Packet Format



   o Sender MEP ID: the MEP ID of the MEP that initiated this packet.

   o Reserved: this field is reserved for the reflector's MEP ID, to be
      added in the SLR.

   o Test ID: a 32-bit unique test identifier.

   o Counter TX: the value of the sender's transmission counter,
      including this packet, at the time of transmission.

   o Reserved: this field is reserved for the SLR corresponding to this
      packet. The reflector uses this field in the SLR for carrying TRX,
      the value of its reception counter.










Mizrahi, et al.       Expires January 14, 2014               [Page 22]


Internet-Draft      TRILL Performance Monitoring             July 2013


6.2.4. SLR Packet Format

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Ver (0) | OpCode        |  Flags (0)    |TLVOffset (16) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Sender MEP ID          |       Reflector MEP ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Test ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Counter TX                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Counter TRX                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 10 SLR Packet Format



   o Sender MEP ID: the MEP ID of the MEP that initiated the SLM that
      this SLR replies to.

   o Reflector MEP ID: the MEP ID of the MEP that transmits this SLR
      message.

   o Test ID: a 32-bit unique test identifier, copied from the
      corresponding SLM message.

   o Counter TX: the value of the sender's transmission counter at the
      time of the SLM transmission.

   o Counter TRX: the value of the reflector's reception counter,
      including this packet, at the time of reception of the
      corresponding SLM packet.








Mizrahi, et al.       Expires January 14, 2014               [Page 23]


Internet-Draft      TRILL Performance Monitoring             July 2013


6.3. Delay Measurement Packet Formats

6.3.1. Timestamp Format

   The timestamps used in DM packets are 64 bits long. These timestamps
   use the 64 least significant bits of the IEEE 1588-2008 (1588v2)
   Precision Time Protocol timestamp format [IEEE1588].

   This truncated format consists of a 32-bit seconds field followed by
   a 32-bit nanoseconds field. This truncated format is also used in
   IEEE 1588v1, in [Y.1731], and in [MPLS-LM-DM].



6.3.2. 1DM Packet Format

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Ver (1) | OpCode        |  Reserved   |T|TLVOffset (16) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timestamp T1                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for 1DM receiving equipment (0)            |
      |                      (for Timestamp T2)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 11 1DM Packet Format



   o T: Type flag. When this flag is set it indicates proactive
      operation, and when cleared it indicates on-demand mode.

   o Timestamp T1: specifies the time of transmission of this packet.

   o Reserved: this field is reserved for internal usage of the 1DM
      receiver. The receiver can use this field for carrying T2, the
      time of reception of this packet.




Mizrahi, et al.       Expires January 14, 2014               [Page 24]


Internet-Draft      TRILL Performance Monitoring             July 2013


6.3.3. DMM Packet Format

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Ver (1) | OpCode        |  Reserved   |T|TLVOffset (32) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timestamp T1                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Reserved for DMM receiving equipment (0)            |
      |                      (for Timestamp T2)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Reserved for DMR (0)                      |
      |                      (for Timestamp T3)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved for DMR receiving equipment               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 12 DMM Packet Format



   o T: Type flag. When this flag is set it indicates proactive
      operation, and when cleared it indicates on-demand mode.

   o Timestamp T1: specifies the time of transmission of this packet.

   o Reserved: this field is reserved for internal usage of the MEP
      that receives the DMM (the reflector). The reflector can use this
      field for carrying T2, the time of reception of this packet.

   o Reserved for DMR: two timestamp fields are reserved for the DMR
      message. One timestamp field is reserved for T3, the DMR
      transmission time, and the other field is reserved for internal
      usage of the MEP that receives the DMR.






Mizrahi, et al.       Expires January 14, 2014               [Page 25]


Internet-Draft      TRILL Performance Monitoring             July 2013


6.3.4. DMR Packet Format

       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |MD-L | Ver (1) | OpCode        |  Reserved   |T|TLVOffset (32) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timestamp T1                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timestamp T2                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timestamp T3                          |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Reserved for DMR receiving equipment               |
      |                      (for Timestamp T4)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .         TLVs                                                  .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 13 DMR Packet Format



   o T: Type flag. When this flag is set it indicates proactive
      operation, and when cleared it indicates on-demand mode.

   o Timestamp T1: specifies the time of transmission of the DMM packet
      that this DMR replies to.

   o Timestamp T2: specifies the time of reception of the DMM packet
      that this DMR replies to.

   o Timestamp T3: specifies the time of transmission of this DMR
      packet.

   o Reserved: this field is reserved for internal usage of the MEP
      that receives the DMR (the sender). The sender can use this field
      for carrying T4, the time of reception of this packet.




Mizrahi, et al.       Expires January 14, 2014               [Page 26]


Internet-Draft      TRILL Performance Monitoring             July 2013


7. Security Considerations

   The security considerations of TRILL OAM are discussed in [OAM-REQ]
   and in [OAM-FRAMEWK]. General TRILL security considerations are
   discussed in [RFCTRILL]. This document does not inflict further
   security considerations.

8. Performance Monitoring Process

   The Performance Monitoring process is made up of a number of
   Performance Monitoring instances, known as PM Sessions. A PM session
   can be initiated between two MEPs on a specific flow and be defined
   as either a Loss Measurement (LM) session or Delay Measurement (DM)
   session.

   The LM session can be used to determine the performance metrics FLR,
   availability, and resiliency. The DM session can be used to determine
   the performance metrics FD, IFDV, FDR, and MFD.

   The PM session is defined by the specific PM function (PM tool) being
   run, and also by the Start Time, Stop time, Message Period,
   Measurement Interval, and Repetition Time. These terms are defined as
   follows:

   o The Start Time is the time that the PM session begins.

   o The Stop Time is the time that the measurement ends.

   o The Message Period is the PDU transmission frequency (the time
      between PDU transmissions).

   o The Measurement Interval is the time period over which
      measurements are gathered and then summarized. The Measurement
      Interval can align with the PM Session duration, but it doesn't
      need to. PDUs during a PM Session are only transmitted during a
      Measurement Interval.

   o The Repetition Time is the time between start times of the
      Measurement Intervals.










Mizrahi, et al.       Expires January 14, 2014               [Page 27]


Internet-Draft      TRILL Performance Monitoring             July 2013


          Measurement Interval     Measurement Interval
          (Completed, Historic)    (In Process, Current)
      |                         |
      |                         |
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ^                 ^ ^                                         ^
      |                 | |                                         |
   Service Enabled     Message                                 Service
                        Period                                 Disabled

         Figure 14 Relationship Between Different Timing Parameters

8.1. LM Statistics

   o Start Time : The time that the current Measurement Interval
      Started.

   o Elapsed Time : The time that the current Measurement Interval has
      been running, in 0.01 seconds.

   o Availability Statistics suspect : Whether the Measurement Interval
      has been marked as suspect. It's started as FALSE at the start of
      a measurement. It's set to true when there's a discontinuity in
      the performance measurement during the Measurement Interval.

   o Availability Forward High Loss Interval: Number of high Loss
      intervals over this time in the forward direction.

   o Availability Backward High Loss Interval: The number of high loss
      intervals over this time in the backward direction.

   o Availability Forward Consecutive High Loss: The number of
      consecutive high loss intervals over the time in the forward
      direction.

   o Availability Backward Consecutive High Loss: The number of
      consecutive high loss intervals over the time in the backward
      direction.

   o Availability Statistics Forward Available: The number of
      availability indicators evaluated as available in the forward
      direction by this MEP during this Measurement Interval.




Mizrahi, et al.       Expires January 14, 2014               [Page 28]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o Availability Statistics Backward Available: The number of
      availability indicators evaluated as available in the backward
      direction by this MEP during this Measurement Interval.

   o Availability Statistics Forward Unavailable: The number of
      availability indicators evaluated as unavailable in the forward
      direction by this MEP during this Measurement Interval.

   o Availability Statistics Backward Unavailable: The number of
      availability indicators evaluated as unavailable in the backward
      direction by this MEP during this Measurement Interval.

   o Availability Statistics Forward Minimum FLR: The minimum one-way
      availability FLR in the forward direction.

   o Availability Statistics Backward Minimum FLR: The minimum one-way
      availability FLR in the backward direction.

   o Availability Statistics Forward Maximum FLR: The maximum one-way
      availability FLR in the forward direction.

   o Availability Statistics Backward Maximum FLR: The maximum one-way
      availability FLR in the backward direction.

   o Availability Statistics Forward Average FLR: The Average one-way
      availability FLR in the forward direction.

   o Availability Statistics Backward Average FLR: The Average one-way
      availability FLR in the backward direction.

8.2. DM Statistics

   o Start Time : The time that the current Measurement Interval
      Started.

   o Elapsed Time : The time that the current Measurement Interval has
      been running, in 0.01 seconds.

   o Availability Statistics suspect : Whether the Measurement Interval
      has been marked as suspect. It's started as FALSE at the start of
      a measurement. It's set to true when there's a discontinuity in
      the performance measurement during the Measurement Interval.

   o Frame Delay Two Way : The two-way frame delay calculated by this
      MEP from the last received PM PDU.




Mizrahi, et al.       Expires January 14, 2014               [Page 29]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o Frame Delay Forward : The frame delay in the forward direction
      calculated by this MEP from the last received PM PDU.

   o Frame Delay Backward : The frame delay in the backward direction
      calculated by this MEP from the last received PM PDU.

   o Inter Frame Delay Variation Two Way : The two-way Inter frame
      delay variation calculated by this MEP.

   o Inter Frame Delay Variation Forward : The last one-way Inter frame
      delay variation in forward direction calculated by this MEP.

   o Inter Frame Delay Variation Backward : The last one-way Inter
      frame delay variation in backward direction calculated by this
      MEP.

   o Frame Delay Two Way Minimum : The minimum two-way frame delay
      calculated by this MEP for this Measurement Interval.

   o Frame Delay Two Way Maximum : The maximum two-way frame delay
      calculated by this MEP for this Measurement Interval.

   o Frame Delay Two Way Average : The average two-way frame delay
      calculated by this MEP for this Measurement Interval.

   o Frame Delay Forward Minimum : The minimum one-way frame delay in
      the forward direction calculated by this MEP for this Measurement
      Interval.

   o Frame Delay Forward Average : The average one-way frame delay in
      the forward direction calculated by this MEP for this Measurement
      Interval.

   o Frame Delay Forward Maximum : The maximum one-way frame delay in
      the forward direction calculated by this MEP for this Measurement
      Interval.

   o Frame Delay Backward Minimum : The minimum one-way frame delay in
      the backward direction calculated by this MEP for this Measurement
      Interval.

   o Frame Delay Backward Average : The average one-way frame delay in
      the backward direction calculated by this MEP for this Measurement
      Interval.





Mizrahi, et al.       Expires January 14, 2014               [Page 30]


Internet-Draft      TRILL Performance Monitoring             July 2013


   o Frame Delay Backward Maximum : The maximum one-way frame delay in
      the backward direction calculated by this MEP for this Measurement
      Interval.

   o Inter Frame Delay Two Way Minimum : The minimum two-way inter-
      frame delay interval calculated by this MEP for this Measurement
      Interval.

   o Inter Frame Delay Two Way Maximum : The maximum two-way inter-
      frame delay interval calculated by this MEP for this Measurement
      Interval.

   o Inter Frame Delay Two Way Average : The average two-way inter-
      frame delay interval calculated by this MEP for this Measurement
      Interval.

   o Inter Frame Delay Forward Minimum : The minimum one-way inter-
      frame delay interval in the forward direction calculated by this
      MEP for this Measurement Interval.

   o Inter Frame Delay Forward Average : The average one-way inter-
      frame delay interval in the forward direction calculated by this
      MEP for this Measurement Interval.

   o Inter Frame Delay Forward Maximum : The maximum one-way inter-
      frame delay interval in the forward direction calculated by this
      MEP for this Measurement Interval.

   o Inter Frame Delay Backward Minimum : The minimum one-way inter-
      frame delay interval in the backward direction calculated by this
      MEP for this Measurement Interval.

   o Inter Frame Delay Backward Average : The average one-way inter-
      frame delay interval in the backward direction calculated by this
      MEP for this Measurement Interval.

   o Inter Frame Delay Backward Maximum : The maximum one-way inter-
      frame delay interval in the backward direction calculated by this
      MEP for this Measurement Interval.

   o Number of PDUs Sent : The count of the number of DMM PDUs sent.

   o Number of PDUs Received : The count of number of DMR received.






Mizrahi, et al.       Expires January 14, 2014               [Page 31]


Internet-Draft      TRILL Performance Monitoring             July 2013


9. IANA Considerations

9.1. OpCode Values

   IANA is requested to assign TRILL OAM OpCode values to the packet
   types defined in this document. The suggested OpCode values are
   identical to the ones defined in [Y.1731]:

      45 : 1DM

      46 : DMR

      47 : DMM

      53 : 1SL

      54 : SLR

      55 : SLM

10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

11. References

11.1. Normative References

   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFCTRILL]    Perlman, R., Eastlake, D., Dutt, D., Gai, S.,
                 Ghanwani, A., "Routing Bridges (RBridges): Base
                 Protocol Specification", RFC 6325, July 2011.

   [OAM-FRAMEWK] Salam, S., Senevirathne, T., Aldrin, S., Eastlake, D.,
                 "TRILL OAM Framework", draft-ietf-trill-oam-framework
                 (work in progress), May 2013.

   [TRILL-FM]    Senevirathne, T., Finn, N., Salam, S., Kumar, D.,
                 Eastlake, D., Aldrin, S., Li, Y., "TRILL Fault
                 Management", draft-tissa-trill-oam-fm (work in
                 progress), May 2013.






Mizrahi, et al.       Expires January 14, 2014               [Page 32]


Internet-Draft      TRILL Performance Monitoring             July 2013


11.2. Informative References

   [OAM-REQ]     Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve,
                 R., "Requirements for Operations, Administration and
                 Maintenance (OAM) in Transparent Interconnection of
                 Lots of Links (TRILL)", RFC 6905, March 2013.

   [Y.1731]      ITU-T Recommendation G.8013/Y.1731, "OAM Functions and
                 Mechanisms for Ethernet-based Networks", July 2011.

   [802.1Q]      "IEEE Standard for Local and metropolitan area
                 networks - Media Access Control (MAC) Bridges and
                 Virtual Bridged Local Area Networks", IEEE Std
                 802.1Q(tm), 2012 Edition, October 2012.

   [IEEE1588]    IEEE TC 9 Instrumentation and Measurement Society,
                 "1588 IEEE Standard for a Precision Clock
                 Synchronization Protocol for Networked Measurement and
                 Control Systems Version 2", IEEE Standard, 2008.

   [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and Delay
                 Measurement for MPLS Networks", RFC 6374, September
                 2011.

   [OAM]         Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
                 D., Mansfield, S., "Guidelines for the use of the OAM
                 acronym in the IETF ", RFC 6291, June 2011.



Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692 Israel

   Email: talmi@marvell.com


   Tissa Senevirathne
   Cisco
   375 East Tasman Drive
   San Jose, CA 95134, USA

   Email: tsenevir@cisco.com



Mizrahi, et al.       Expires January 14, 2014               [Page 33]


Internet-Draft      TRILL Performance Monitoring             July 2013


   Samer Salam
   Cisco
   595 Burrard Street, Suite 2123
   Vancouver, BC V7X 1J1, Canada

   Email: ssalam@cisco.com


   Deepak Kumar
   Cisco
   510 McCarthy Blvd,
   Milpitas, CA 95035, USA

   Phone : +1 408-853-9760
   Email: dekumar@cisco.com


   Donald Eastlake 3rd
   Huawei USA R&D
   155 Beaver Street
   Milford, MA 01757 USA
   Phone: +1-508-333-2270
   Email: d3e3e3@gmail.com

























Mizrahi, et al.       Expires January 14, 2014               [Page 34]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/