Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)
draft-mizrahi-trill-loss-delay-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Tal Mizrahi , Tissa Senevirathne , Samer Salam , Donald E. Eastlake 3rd | ||
| Last updated | 2013-02-18 | ||
| Replaced by | draft-ietf-trill-loss-delay, RFC 7456 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mizrahi-trill-loss-delay-00
TRILL Working Group T. Mizrahi
Internet Draft Marvell
Intended status: Standards Track T. Senevirathne
Expires: August 2013 S. Salam
Cisco
D. Eastlake 3rd
Huawei
February 18, 2013
Loss and Delay Measurement in
Transparent Interconnection of Lots of Links (TRILL)
draft-mizrahi-trill-loss-delay-00.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 August 18, 2013.
Mizrahi, et al. Expires August 18, 2013 [Page 1]
Internet-Draft TRILL Performance Monitoring February 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 ......... 5
3.1. Peformance Monitoring Granularity ....................... 6
3.2. One-Way vs. Two-Way Performance Monitoring .............. 6
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) ......................... 8
4.1.1. 1SLM Message Transmission .......................... 9
4.1.2. 1SLM Message Reception ............................. 9
4.2. Two-Way Loss Measurement (TWLM) ........................ 10
4.2.1. SLM Message Transmission .......................... 11
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) ....................... 15
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 August 18, 2013 [Page 2]
Internet-Draft TRILL Performance Monitoring February 2013
6.2.1. Counter Format .................................... 20
6.2.2. 1SLM 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
6.4. Reflector Entropy TLV .................................. 27
7. Security Considerations ..................................... 27
8. IANA Considerations ......................................... 27
8.1. OpCode Values .......................................... 27
8.2. TLV Type ............................................... 28
9. Acknowledgments ............................................. 28
10. References ................................................. 28
10.1. Normative References .................................. 28
10.2. Informative References ................................ 28
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 delay variation.
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 ones defined in [Y.1731].
Mizrahi, et al. Expires August 18, 2013 [Page 3]
Internet-Draft TRILL Performance Monitoring February 2013
o Loss Measurement (LM): the LM protocol measures the 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 counters of transmitted and received
packets.
This document does not define an LM protocol that computes the
packet loss of data-plane traffic. 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].
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 LM test,
and a specific observation period.
o Far-end packet loss - the number of packets lost on the path from
the local RBridge to the remote RBridge in a specific LM test, 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 LM test, and
a specific observation period.
Mizrahi, et al. Expires August 18, 2013 [Page 4]
Internet-Draft TRILL Performance Monitoring February 2013
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
MD Maintenance Domain
MD-L Maintenance Domain Level
MEP Maintenance End Point
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
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 are
used by two types of Maintenance Points (MPs); Maintenance End Points
(MEPs) and Maintenance Intermediate Points (MIPs).
Mizrahi, et al. Expires August 18, 2013 [Page 5]
Internet-Draft TRILL Performance Monitoring February 2013
+-------+ +-------+ +-------+
| | | | | |
| 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 MEP in the campus. Performance monitoring is
performed in the context of a specific Maintenance Domain (MD).
A MEP MUST support generation of PM messages, response to PM messages
and computation of the packet loss and packet delay.
The PM functionality defined in this document is not applicable to
MIPs.
3.1. Peformance 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.
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 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
Mizrahi, et al. Expires August 18, 2013 [Page 6]
Internet-Draft TRILL Performance Monitoring February 2013
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 SHOULD support one-way performance monitoring. A MEP 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 refelector, 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.
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 MUST support two-way PM. A MEP 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
than the Flow Entropy of the path from RB2 to RB1. This document
defines a Reflector Entropy TLV (Section 6.4.), 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.
Mizrahi, et al. Expires August 18, 2013 [Page 7]
Internet-Draft TRILL Performance Monitoring February 2013
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.
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.
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 (1SLM) messages. The packet format of the 1SLM message is
specified in Section 6.2.2. Figure 2 illustrates an OWLM message
exchange.
TXp TXc
Sender --------------------------------------
\ \
\ 1SLM . . . \ 1SLM
\ \
\/ \/
Receiver --------------------------------------
RXp RXc
Figure 2 One-Way Loss Measurement
Mizrahi, et al. Expires August 18, 2013 [Page 8]
Internet-Draft TRILL Performance Monitoring February 2013
The OWLM procedure uses a set of 1SLM messages to measure the packet
loss rate. The figure shows two non-consecutive messages from the
set.
The sender maintains a counter of transmitted 1SLM messages, and
includes the value of this counter, TX, in each 1SLM message it
transmits. The receiver maintains a counter of received 1SLM
messages, RX, and can calculate the loss rate by comparing its
counter values to the counter values received in the 1SLM messages.
In Figure 2, the subscript 'c' is short for current, and 'p' is short
for previous.
4.1.1. 1SLM 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 1SLM messages, allowing the receiver to
perform the measurement based on this set.
A MEP that supports OWLM MUST support unicast transmission of 1SLM
messages.
A MEP that supports OWLM MAY support multicast transmission of 1SLM
messages.
The sender MUST maintain a packet counter for each peer MEP and test
ID. Every time the sender transmits a 1SLM packet it increments the
corresponding counter, and then integrates the value of the counter
into the <Counter TX> field of the 1SLM packet.
The 1SLM message MAY be sent with a Data TLV, allowing loss
measurement for various packet sizes.
4.1.2. 1SLM Message Reception
The receiver MUST maintain a reception counter for each peer MEP and
test ID. Upon receiving a 1SLM packet, the receiver MUST verify that:
o The 1SLM packet is destined to the current MEP.
o The packet's MD level matches the MEP's MD level.
Mizrahi, et al. Expires August 18, 2013 [Page 9]
Internet-Draft TRILL Performance Monitoring February 2013
If both conditions are satisfied, the receiver increments the
corresponding packet counter, and records the new value of the
counter, RX1.
A MEP that supports OWLM MUST support reception of both unicast and
multicast 1SLM messages.
The receiver computes the one-way packet loss with respect to a
measurement interval. A measurement interval includes a sequence of
1SLM message. 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 init value.
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 1SLM receiver MUST support reception of 1SLM 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.
Mizrahi, et al. Expires August 18, 2013 [Page 10]
Internet-Draft TRILL Performance Monitoring February 2013
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.
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 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.
Mizrahi, et al. Expires August 18, 2013 [Page 11]
Internet-Draft TRILL Performance Monitoring February 2013
A sender MAY include a Reflector Entropy TLV in an SLM message. The
Reflecotr Entropy TLV format is specified in Section 6.4.
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 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.
o The reflector assigns its MEP ID in the <Reflector MEP ID> field.
o If the received SLM includes a Reflector Entropy TLV (see Section
6.4.), 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.
Mizrahi, et al. Expires August 18, 2013 [Page 12]
Internet-Draft TRILL Performance Monitoring February 2013
4.2.3. SLR Message Reception
The sender MUST maintain a reception counter, RX, for each peer MEP
and 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 receiver computes the one-way packet delay with respect to a
measurement interval. A measurement interval includes a sequence of
1SLM message. The one-way packet delay is performed 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):
The sender computes the packet loss with respect to a measurement
interval. A measurement interval includes a sequence of SLM messages,
and their corresponding SLR messages. 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'
(Figure 3):
far-end packet loss = (TXc-TXp) - (TRXc-TRXp) (2)
near-end packet loss = (TRXc-TRXp) - (RXc-RXp) (3)
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 init 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.
Mizrahi, et al. Expires August 18, 2013 [Page 13]
Internet-Draft TRILL Performance Monitoring February 2013
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:
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 a OWDM protocol MUST
be time-synchronized. The method used for synchronizing the two MEPs
is outside the scope of this document.
Mizrahi, et al. Expires August 18, 2013 [Page 14]
Internet-Draft TRILL Performance Monitoring February 2013
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 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.
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
Mizrahi, et al. Expires August 18, 2013 [Page 15]
Internet-Draft TRILL Performance Monitoring February 2013
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
Reflecotr Entropy TLV format is specified in Section 6.4.
A DMM MAY be sent with a Data TLV, allowing packet delay measurement
for various packet sizes.
The sender incorporates the DMM packet's time of transmission into
the <Timestamp T1> field.
Mizrahi, et al. Expires August 18, 2013 [Page 16]
Internet-Draft TRILL Performance Monitoring February 2013
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 (see Section
6.4.), 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.
o The packet's MD level matches the MEP's MD level.
Mizrahi, et al. Expires August 18, 2013 [Page 17]
Internet-Draft TRILL Performance Monitoring February 2013
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 August 18, 2013 [Page 18]
Internet-Draft TRILL Performance Monitoring February 2013
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Link Header . Variable
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ TRILL Header + 8 octets
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Flow Entropy . Fixed Size
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM EtherType | 2 octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. 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 August 18, 2013 [Page 19]
Internet-Draft TRILL Performance Monitoring February 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 August 18, 2013 [Page 20]
Internet-Draft TRILL Performance Monitoring February 2013
6.2.2. 1SLM 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 | Version | OpCode | Flags (0) |TLVOffset (12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender MEP ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Test ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter TX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 1SLM Packet Format
o Sender MEP ID: the MEP ID of the MEP that initiated the 1SLM.
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 August 18, 2013 [Page 21]
Internet-Draft TRILL Performance Monitoring February 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 | Version | 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 August 18, 2013 [Page 22]
Internet-Draft TRILL Performance Monitoring February 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 | Version | 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 August 18, 2013 [Page 23]
Internet-Draft TRILL Performance Monitoring February 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 | Version | OpCode | Flags |TLVOffset (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for 1DM receiving equipment (0) |
| (for Timestamp T2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11 1DM Packet Format
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 August 18, 2013 [Page 24]
Internet-Draft TRILL Performance Monitoring February 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 | Version | OpCode | Flags (0) |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 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 August 18, 2013 [Page 25]
Internet-Draft TRILL Performance Monitoring February 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 | Version | OpCode | Flags (0) |TLVOffset (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T2 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp T3 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved for DMR receiving equipment |
| (for Timestamp T4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. TLVs .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13 DMR Packet Format
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 August 18, 2013 [Page 26]
Internet-Draft TRILL Performance Monitoring February 2013
6.4. Reflector Entropy TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (72) | Length (129) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Reflector Flow Entropy .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14Reflector Entropy TLV Format
o Type: the value 72 (see Section 8.2.) represents the Reflector
Entropy TLV.
o Length: the length of the Reflector Entropy TLV is set to 129.
o Reserved: ignored by the recipient.
o Reflector Flow Entropy: the 128-octet Flow Entropy to be used by
the reflector.
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. IANA Considerations
8.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:
81 : SLM
80 : SLR
79 : 1SLM
83 : 1DM
Mizrahi, et al. Expires August 18, 2013 [Page 27]
Internet-Draft TRILL Performance Monitoring February 2013
85 : DMM
84 : DMR
8.2. TLV Type
IANA is requested to assign the following TLV type:
72 : Reflector Entropy TLV
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
10. References
10.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), November 2012.
[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), February 2013.
10.2. Informative References
[OAM-REQ] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve,
R., "Requirements for Operations, Administration and
Maintenance (OAM) in TRILL (Transparent
Interconnection of Lots of Links)", draft-ietf-trill-
oam-req (work in progress), January 2013.
[Y.1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and
Mechanisms for Ethernet-based Networks", July 2011.
Mizrahi, et al. Expires August 18, 2013 [Page 28]
Internet-Draft TRILL Performance Monitoring February 2013
[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
Samer Salam
Cisco
595 Burrard Street, Suite 2123
Vancouver, BC V7X 1J1, Canada
Email: ssalam@cisco.com
Mizrahi, et al. Expires August 18, 2013 [Page 29]
Internet-Draft TRILL Performance Monitoring February 2013
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 August 18, 2013 [Page 30]