Internet DRAFT - draft-guo-bfd-pm-extension
draft-guo-bfd-pm-extension
Network working group X. Guo
Internet Draft M. Chen
Category: Standards Track K.Chan
Created: March 10, 2009 Huawei Technologies Co.,Ltd
Expires: September 2009
BFD Extensions in Support of Performance Measurement
draft-guo-bfd-pm-extension-01.txt
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 15, 2009.
Copyright Notice
Copyright (c) 2009 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.
Guo, Chen and Chan. Expires September 10, 2009 [Page 1]
Internet-Draft BFD extensions for PM March 2009
Abstract
This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol to support Performance Measurement for
IP/MPLS network. Specifically, it defines BFD extensions for
measuring packet loss, delay and delay variation for arbitrary paths
between systems.
Conventions used in this document
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 RFC-2119 [RFC2119].
Table of Contents
1. Introduction................................................2
2. Abbreviation................................................3
3. Terminology.................................................3
4. Motivations.................................................4
5. Extensions to BFD...........................................6
5.1. Packet Loss TLV.........................................8
5.2. Packet Delay TLV........................................9
6. Theory of Operation........................................11
6.1. Packet Loss Measurement................................11
6.2. Packet Delay Measurement...............................16
6.3. Packet Delay variation Measurement.....................19
7. Security Considerations.....................................19
8. IANA Considerations........................................19
9. Acknowledgments............................................20
10. References................................................20
10.1. Normative References..................................20
10.2. Informative References................................20
Authors' Addresses............................................21
1. Introduction
The Bidirectional Forwarding Detection protocol [BFD] provides a
mechanism for liveness detection of arbitrary paths between systems.
It is intended to provide low-overhead, short-duration detection of
failures in the path between adjacent forwarding engines, including
the interfaces, data link(s), and to the extent possible the
forwarding engines themselves.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 2]
Internet-Draft BFD extensions for PM March 2009
BFD could be used in many scenarios for failure detection, which
includes one-hop [BFD-1HOP], multi-hop [BFD-MULTI], MPLS LSP [BFD-
MPLS], PW VCCV [BFD-VCCV] failure detection. And according to
different requirements and situations, BFD provides several
combinations of one of those two operating modes (Asynchronous mode
and Demand mode) and an additional function (Echo Function) for
selection.
BFD is designed for failure detection, and so far, most of the
applications of BFD are for liveness detection. Based on the
mechanisms and functions provided by BFD, BFD could be used for
Performance Measurement of arbitrary paths between systems. In this
document, the performance is specified to packet loss, packet delay
and packet delay variation. This document describes methods and BFD
extensions for Performance Measurement.
2. Abbreviation
PM: Performance Measurement
PLM: Packet Loss Measurement
PDM: Packet Delay Measurement
PDVM: Packet Delay Variation Measurement
3. Terminology
Proactive OAM: Proactive OAM refers to OAM actions which are carried
out continuously to permit proactive reporting of fault and/or
performance results.
On-demand OAM: On-demand OAM refers to OAM actions which are
initiated via manual intervention for a limited time to carry out
diagnostics. On-demand OAM can result in singular or periodic OAM
actions during the diagnostics time interval.
Dual-ended packet loss: Each end sends periodic Dual-ended PLM
packets to its peer end to facilitate packet loss measurements at
the peer end. Dual-ended PLM is used as proactive PM.
Single-ended packet loss: The active node sends Single-ended PLM
request massage to the passive node and receives PLM reply packet to
carry out packet loss measurements. And the PLM reply packet is sent
by the passive when receiving PLM request massage form the active.
Single-ended PLM is used for on-demand PM.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 3]
Internet-Draft BFD extensions for PM March 2009
Near-End packet loss: Near-end packet loss refers to packet loss
associated with ingress data packets, and packet loss measurement is
performed on the egress node.
Far-end packet loss: Far-end packet loss refers to packet loss
associated with egress data packets, and packet loss measurement is
performed on the egress node.
One-way packet delay: is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of that packet by the destination
node.
Two-way packet delay: is the time elapsed from the start of
transmission of the first bit of the packet by a source node until
the reception of the last bit of the loop-backed packet by the
same source node, when the loopback is performed at the packet's
destination node.
4. Motivations
Currently, more and more new real-time services (e.g. Voice, Video,
Multimedia etc.) are provided using IP/MPLS networks, these new
applications have diverse Quality of Service (QoS) requirements that
are significantly different from the traditional best-effort service.
With the rapid growth of the network and new applications, it brings
a serious challenge to IP/MPLS network for performance management
and monitoring, which is crucial for IP/MPLS service provider to
provide guaranteed services, as well as assure the users that they
received the service according to the Services Level Agreements
(SLAs) they negotiated with their service provider.
The requirements of Performance Measurement are stated in [Y.1541],
[Y.1710], [RFC 4377], [MPLS-TP-OAM-REQ] and other documents. The
requirements of Performance Measurement could be simply summed up as
follows:
o Performance Measurement SHOULD at least include packet loss,
packet delay and packet delay variation.
o For packet loss measurement,
- it SHOULD support bidirectional point-to-point paths and
unidirectional point-to-point and point-to-multipoint
paths, and
Guo, Chen, and Chan. Expires September 10, 2009 [Page 4]
Internet-Draft BFD extensions for PM March 2009
- it SHOULD support proactive and on-demand mode, and
for proactive, it SHOULD support both dual-ended
and single-ended modes;
for on-demand, it SHOULD support single-ended mode;
for both of proactive and on-demand, they SHOULD
Near-End and Far-End;
o For packet delay and delay variation,
- it SHOULD support on-demand mode, and
- it SHOULD support both one-way and two-way modes,
Packet loss, delay and delay variation are the most typical
performance metrics. By measuring these metrics of the specific
paths in a network, service providers could detect the performance
degradation as soon as possible and take actions proactively. And an
OAM tool with Performance Measurement could also be used for
assisting in failure location when a failure occurs in a large and
complex network. That is, a set of performance monitoring tools are
desired for network operators and service providers. But the fact is
that there are no feasible standards and universal implementation
for IP/MPLS performance measurement.
In this document, BFD is proposed for performance measurement,
because BFD has the following characteristics which could satisfy
the requirements of Performance Measurement indicated above:
o BFD is originally designed for OAM and currently is used for
failure detection, it is reasonable if BFD is used for
performance measurement without adding much more complexity to
BFD. BFD [BFD-BASE] has already defined TLV (Type-Length-Value)
mechanism for Authentication purpose, two more new TLVs are
proposed by this document for performance measurement, with
minimum added complexity to BFD.
o Normally, BFD is implemented in the data path (line cards), so
it's very easy for BFD to get the forwarding statistic
information (e.g., received/transmitted packet numbers of a
specific path) timely, hence if BFD is used for performance
measurement, it will increase the accuracy of performance
measurement.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 5]
Internet-Draft BFD extensions for PM March 2009
o BFD protocol is very simple, for its low-overhead and
efficiency in failure detection, it is implemented by most of
the vendors on their devices and it is widely deployed in the
networks. If BFD is used for performance measurement, many
existing mechanisms (e.g., session establishment, parameter
negotiation, control packet formats) of BFD could be reused for
performance measurement. Hence there is no need to define a new
protocol.
o BFD is applicable to IP and MPLS, and point-to-point and point-
to-multipoint paths as well. So BFD with performance
measurement extensions is also applicable to IP and MPLS, and
point-to-point and point-to-multipoint path.
o BFD defines two operating modes, which are referred to as
Asynchronous and Demand mode. These two modes could be exactly
used to fulfill the requirements of Performance Measurement,
which are required to support proactive and on-demand, one-way
and two-way, as well as single-ended and dual-ended.
o BFD protocol support more than one authentication mechanism to
allow the receiving system to determine the validity of the
received packet. All OAM massages need Authentication mechanism
which is suggested by [MPLS-TP-OAM-REQ]. Performance
measurement as one of OAM tools also needs authentication for
security consideration. If BFD be used for performance
measurement, the authentication mechanisms of BFD MAY be reused,
and it no need to redefined a new set.
So, BFD is applicable to be used for Performance Measurement. The
detailed definitions and procedures are discussed in the following
sections.
5. Extensions to BFD
The BFD control packet is consisted of a Mandatory section and an
Optional Authentication Section, which is defined in [BFD]. The
Authentication Section is actually a Type-Length-Value (TLV)
structure that is indicated by the A (Authentication present) bit
whether the Authentication Section exists. There are five
Authentication TLVs that are defined in [BFD] and each of them is
identified by the Auth Type.
In this document, two new TLVs, which are referred to as Packet Loss
TLV and Packet Delay TLV, are added to the ''Optional'' Section of BFD
control packet for packet loss, delay and delay variation
Guo, Chen, and Chan. Expires September 10, 2009 [Page 6]
Internet-Draft BFD extensions for PM March 2009
measurement. Based on the reality of the current definition and
usage of BFD header, there is no more free fields and flags that
could be used to indicate whether these new TLVs exists, hence the
receiver can not correctly intercept and interpret the BFD control
packet with performance measurement purpose. So, there are two
solutions proposed in this document:
o Change the semantic of the A (Authentication Section presents)
bit:
Currently, the Optional Section is defined only for carrying
Authentication TLVs. The Performance Measurement TLVs defined
in this document could be carried in the Optional Section, it
just needs to change the special A bit to a common O (Optional
Section presents) bit, if the O bit is set in a received BFD
control packet, it indicates that the Optional Section is
present. Then how to process the TLVs carried in the Optional
Section is based on the type a specific TLV.
Since there are several Authentication types defined in [BFD],
presumably, the process of the Authentication TLVs is most like
this: the receiver is indicated whether the Optional Section
exists by checking the A bit, then steps into a specific
Authentication procedure based on the TLV type. So changing the
semantic of A bit to O bit will not bring much impact to the
processing of the existing Authentication procedure,
implementations using current definitions may be not impacted
by the change at all.
o Version 2 BFD:
In order not to impact the current BFD implements and provide
better backward compatibility, it may be a good idea to define a
new version of BFD. The Mandatory Section of the new version BFD
Control packet is defined as follows:
Guo, Chen, and Chan. Expires September 10, 2009 [Page 7]
Internet-Draft BFD extensions for PM March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers | Diag |Sta|P|F|C|O|D|M| Detect Mult | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| My Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Your Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired Min TX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Required Min Echo RX Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Compared to version 1, the version number is updated to 2, the A
bit is changed to O bit.
[Discussion: IMHO, there is a bit of waste that the ''Detect Mult''
field is assigned 8 bits, actually, 6 bits is enough, hence there
could be reserved two more bits for use by any other future
defined functions.]
5.1. Packet Loss TLV
The Packet Loss TLV is defined for packet loss measurement, by
carrying some essential statistic information (e.g., the number of
transmitted packets, the number of received packet), which could be
used by each of the two ends of a specific path to perform packet
loss ratio calculation. The format of the Packet Loss TLV is as
follows:
0 1 2 3
Guo, Chen, and Chan. Expires September 10, 2009 [Page 8]
Internet-Draft BFD extensions for PM March 2009
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 | Length | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxPacCount_l |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RxPacCount_l |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxPacCount_f |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Packet Lost TLV
The Packet Loss TLV is TLV type TBD, and is 12 bytes in length, the
value of length includes the Type and Length field.
The Sequence field specifies the sequence number of a BFD Packet
Loss Measurement (PLM) packet. It is generated by the end who
initiates the measurement, the middle nodes and other side MUST not
change the sequence number when propagate or reply the PLM packet.
The sequence number could be used for loss detection of PLM packets
or for the initiator to make sure the received PLM packet is a
response of a previous PLM packet sent by itself.
The TxPacCount_l contains the local counter of the transmitted
packets from the beginning of this measurement to the time when
sending this BFD PLM packet.
The RxPacCount_l contains the local counter of the received packets
from the beginning of this measurement to the time when received a
BFD PLM packet.
The TxPacCount_f is copied from the TxPacCount_l of the last
received BFD PLM packet when needs to reply a received BFD PLM
packet with the statistic information back to initiator of this
measurement for packet loss ratio calculation.
The detailed procedures on how to use the Packet Loss TLV in
different scenarios for packet loss measurement are described in
Section 4 of this document.
5.2. Packet Delay TLV
The Packet Delay TLV is defined for packet delay and delay variation
measurement. The Packet Delay TLV is TLV type TBD, and is 12 bytes
Guo, Chen, and Chan. Expires September 10, 2009 [Page 9]
Internet-Draft BFD extensions for PM March 2009
in length, the value of length includes the Type and Length field.
The format of the Packet Delay TLV is as follows:
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 | Length | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxTimeStamp_a |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RxTimeStamp_p |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxTimeStamp_p |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Packet Delay TLV
The Sequence field specifies the sequence number of a BFD Packet
Delay Measurement (PDM) packet. It is generated by the end who
initiates the measurement, the middle nodes and other side MUST not
change the sequence number when propagate or reply the PDM packet.
The sequence number could be used for PDM packets loss detection or
for the initiator to make sure the received PDM packet is a response
of a previous PDM packet sent by itself.
TxTimeStamp_a specifies the time stamp of the Active_End when
transmitting a BFD Packet Delay Measurement (PDM) request packet.
RxTimeStamp_p specifies the time stamp of the Passive_End when
receiving a BFD PDM request packet.
TxTimeStamp_p specifies the time stamp of the passive end when
transmitting the BFD PDM reply packet to a previous BFD PDM request
packet.
Active_End is the node that initiates the measurement, Passive_End
is the node that will not initiate a measurement and just act to, if
needed, the Active_End when received a PDM request packet.
The detailed procedures on how to use the Packet Delay TLV in
different scenarios for packet delay and delay variation measurement
are described in Section 4 of this document.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 10]
Internet-Draft BFD extensions for PM March 2009
6. Theory of Operation
BFD defines two different operating modes, which are known as
Asynchronous mode and Demand mode.
With asynchronous mode, the systems periodically send BFD Control
packets to one another, and each system judges and declares the
session down independently if a number of those packets in a row are
not received. The Asynchronous mode may be used to achieve a pro-
active Performance Measurement that can be carried out continuously
to permit proactive reporting of performance results.
For demand mode, once a BFD session is established, the two systems
will stop sending BFD Control packets, except when the system feels
the need to verify connectivity explicitly. Demand mode may operate
independently in each direction, or simultaneously. The BFD demand
mode may be used to support an on-demand Performance Measurement
mechanism.
6.1. Packet Loss Measurement
To perform packet loss measurement of a specific path, two things
need to be done: 1)whatever each of the two ends will calculate the
ratio of packet loss, it gets to know the number of not only the
transmitted packets at the sender, but the received packets at the
receiver in a certain measurement period, 2)and the receiver gets to
be aware of the right time when to start counting and when to
calculate the number of received packets for a specific measurement
period as well.
In this document, the Packet Loss TLV is defined for the two ends of
a specific path to exchange statistic information of the transmitted
and/or received packets for the certain measurement periods, which
could be used for each of the two ends to perform packet loss
calculation.
Since this draft intends to use a PLM packet where TxPacCount_l is
set to zero to notify the receiver to start counting, and subsequent
PLM packets are used to notify the receiver when to count the number
of received packets from the beginning of counting time to the time
when received the last PLM packet. So, with such mechanism, time
synchronization is not necessary.
Depending on the scenario, the operators could choose any side of
the two systems for packet loss ratio calculation, which results in
several measurement modes/methods as described below for selection.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 11]
Internet-Draft BFD extensions for PM March 2009
Near-end PLM is to measure the loss of packet sending from the far
end, and on the contrary, the for-end PLM is to measure the loss of
packet sending by this self end.
For the difference of operation, Packet loss measurement may be
performed in two modes, dual-ended PLM and single-ended PLM.
4.1.1 Dual-ended PLM
+-+-+ +-+-+
| A | | B |
+-+-+ +-+-+
Start T1|---BFD PLM Packet --->|TT1
| |
| |
T2|---BFD PLM Packet --->|TT2 First Calculation
| |
| . |
| . |
| . |
| |
Tn|---BFD PLM Packet --->|TTn Nth Calculation
| |
| |
| |
Figure 3: Dual-ended near-end Packet lost measurement
Dual-ended PLM is the mode that each end independently sends
periodic BFD PLM packets to the other end, the end who receives the
PLM packets will perform packet loss ratio calculation. Dual-ended
PLM can be used as a pro-active measurement mode. For dual-ended PLM,
it is expected to support two measurements that are referred to as
Near-end and Far-end. Near-end PLM is intended to measure the packet
loss sent from the other ends, and on the contrary, Far-end PLM
means that the node performs packet loss calculation for the packets
sent by itself.
Figure 3 describes the flow of Near-end packet loss measurement,
where A is the node who initiates the packet loss measurement and B
is the node who is responsible for packet loss ratio calculation,
and vice versa.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 12]
Internet-Draft BFD extensions for PM March 2009
When dual-ended PLM is enabled, if node B is configured to support
near-end PLM, A will send periodic BFD PLM packet to B, and start
counting the transmitted packets. The BFD PLM packets carry the PLM
TLV, in which the parameters TxPacCount_l and sequence will be
included. For near-end measurement, the other two parameters,
RxPacCount_l and TxPacCount_f, are not needed and should be ignored
on receipt, the two fields MUST be set to zero when transmitting.
When received a PLM packet, node B will read and record the value of
Local Received Packet Counter (LRPC), which contains the numbers of
the received packets, as well the parameter TxPacCount_l from the
received PLM packet. By using the statistic information carried/ in
the PLM packet and LRPC this time and the previous, node B can
perform near-end packet loss measurement. Given that Tn1 and Tn2 are
the time of node A sending two different PLM packets, and TTn1 and
TTn2 are correspondingly the time of the two PLM packets received by
node B. With the formula as follows, node B could calculate the
numbers of loss packets. The calculation interval is based on the
sending interval of PLM packets, it can be set to any reasonable
value as requirements (e.g., it could be set to 100ms). The sequence
could be used for loss detection of PLM packets.
Packet Loss [near-end]=|TxPacCount_l[Tn2] - TxPacCount_l[Tn1]|-
|RxPacCountl[TTn2]- RxPacCountl[TTn1]|
+-+-+ +-+-+
| A | | B |
+-+-+ +-+-+
Start T1|---BFD PLM Packet --->|TT1
|<---BFD PLM Packet ---|
| |
T2|---BFD PLM Packet --->|TT2
First Calculation|<---BFD PLM Packet ---|
| . |
| . |
| . |
Tn|---BFD PLM Packet --->|TTn
Tn Nth Calculation|<---BFD PLM Packet ---|
| |
| |
Figure 4: Dual-ended far-end Packet lost measurement
Guo, Chen, and Chan. Expires September 10, 2009 [Page 13]
Internet-Draft BFD extensions for PM March 2009
Figure 4 describes the flow of far-end packet loss measurement. Node
A sends PLM packets to node B and performs the calculation of packet
loss when received for these packets sending by itself.
When dual-ended PLM is enabled, and A is configured to support far-
ended PLM measurement, the same as near-ended PLM, node A will send
periodic BFD PLM packet with the TxPacCount_l and sequence
parameters set to node B. The difference is that, node B SHOULD also
send periodic BFD PLM packets to node A, with parameters
RxPacCount_l and TxPacCount_f that specify the value of local
received packet counter (LRPC) and the value of TxPacCount_l which
is carried in a previous PLM packet received from node A. The same
as near-end packet loss measurement, when received a PLM packet from
node B, node A will record the parameters from the PLM packet and
read the value of LRPC, then using parameters of this time and the
previous, node A can perform far-end packet loss calculation. Tn1
and Tn2 specify the time of two difference PLM packets sending from
node A, and TTn1 and TTn2 are the corresponding time of node B
received these two packets. The formula of calculation is as follow.
Packet Loss [far-end]=|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]| -
|RxPacCount_l[TTn2] - RxPacCount_l[TTn1]|
Near-end and Far-end could be enabled at the same time in one node.
4.1.2 Single-ended PLM
Guo, Chen, and Chan. Expires September 10, 2009 [Page 14]
Internet-Draft BFD extensions for PM March 2009
+-+-+ +-+-+
| A | | B |
+-+-+ +-+-+
Active T1|---BFD PLM Request--->|TT1 Passive
|<---BFD PLM Reply ----|
| |
T2|---BFD PLM Request--->|TT2
First Calculation |<---BFD PLM Reply ----|
| . |
| . |
| . |
| |
Tn|---BFD PLM Request--->|TTn
Nth Calculation |<---BFD PLM Reply ----|
| |
| |
Figure 5: Single-ended Packet loss measurement
Single-ended means that the side touches off the measurement and
will perform the packet loss calculation by itself, which implies
that the other side should send the packets statistics of the
measurement back to the initiator.
Single-ended PLM can be used as an on-demand measurement mode. Once
this mode is enabled, the active system sends BFD PLM request packet
with the PLM TLV to the passive node, and receives the BFD PLM reply
packet from the peer, then performs packet loss calculation. BFD
demand mode is applicable for being used to support Single-ended PLM.
The flow of single-ended Packet Loss Measurement is described as
Figure 5. Node A is the active system which by sending the BFD PLM
request packet to node B to initiate a specific packet loss
measurement. Node B is the passive node that will send PLM reply
packet back to node A when received a PLM request packet.
The same as Dual-ended packet loss measurement, Single-ended PLM is
also expected to support Near-end and Far-end measurement. When
Single-ended PLM is enabled on node A, it will initiate a specific
measurement by sending BFD PLM request packets to node B. For Far-
end PLM, the TxPacCount_l containing the number of transmitted
packets MUST be included in the PLM TLV. When a specific measurement
started, the node starts to count the transmitted and received
Guo, Chen, and Chan. Expires September 10, 2009 [Page 15]
Internet-Draft BFD extensions for PM March 2009
packets. When received a PLM request packet, node B will send A the
PLM reply packet with the PLM TLV containing the three counters
TxPacCount_l, RxPacCount_l and TxPacCount_f, and the sequence copied
from a previous PLM request packet. TxPacCount_f is identical to
TxPacCount_l of the last received PLM request packet. When doing
Near-end PLM, TxPacCount_l MUST be included in the PLM TLV and the
other two counter are not necessary and should be set to zero. For
Far-end PLM, RxPacCount_l and TxPacCount_f MUST be included and the
other counter TxPacCount_l is not necessary and should be set to
zero. When Near-end and Far-end PLM are expected to be supported at
the same time, the three counters MUST be included. When node A
receives a PLM reply packet,it will read and record the counters
from the PLM reply packet, as well the value of local packet
reception counter. Based on the counters from any twice records
which may be continuous or not, node A can perform packet loss
calculation of the period.
Tn1 and Tn2 specify the time of two difference PLM request packets
sending from A, and TTn1 and TTn2 are the corresponding time of B
received these two packets.
The formulas of Near-end and Far-end are as follows.
Packet Loss [near-end]=|TxPacCount_l[Tn2] -TxPacCount_l[Tn1]| -
|RxPacCountl[TTn2] - RxPacCountl[TTn1]|
Packet Loss [far-end]=|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]| -
|RxPacCount_l[TTn2] - RxPacCount_l[TTn1]|
The formulas below are for packet loss ratio:
Packet Loss Ratio[near-end] = (Packet Loss[near-end]
/(|TxPacCount_l[Tn2] -TxPacCount_l[Tn1]|)) *100%
Packet Loss Ratio[far-end] = (Packet Loss[far-end]
/(|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]|)) *100%
6.2. Packet Delay Measurement
Packet delay measurement can be used for on-demand Performance
Measurement. In this document, BFD control packets with PDM TLV
containing the timestamps of sending and receiving PDM packet
between the two systems are used to perform packet delay and delay
variation measurement. Packet delay measurement is performed by
Guo, Chen, and Chan. Expires September 10, 2009 [Page 16]
Internet-Draft BFD extensions for PM March 2009
sending periodic BFD PDM packets from one system to another, and two
modes that are referred to as one-way and two-way delay measurement
are defined to be applied for different situations.
4.2.1 One-way PDM
+-+-+ +-+-+
| A | | B |
+-+-+ +-+-+
Start T1|---BFD PDM Packet --->|TT1
| |
| |
T2|---BFD PDM Packet --->|TT2 First Calculation
| |
| . |
| . |
| . |
| |
Tn|---BFD PDM Packet --->|TTn Nth Calculation
| |
| |
| |
Figure 6: One-Way Packet Delay measurement
In one-way mode, one system sends BFD PDM packet carrying the local
timestamp to facilitate packet delay measurement on the other end.
Both BFD demand mode or asynchronous mode are applicable for one-way
delay measurement. Figure 6 describes the flow of One-way PDM.
When One-way packet delay measurement is enabled, the active node A
will transmit BFD PDM packets with the PDM TLV, in which the
TxTimeStamp_a and sequence MUST be included. When received a PDM
packet, according to the TxTimeStamp_a from the received PDM packet
and the local timestamp, node B could perform packet delay
calculation. The formula is as follows.
Packet Delay [one-way] = RxTime_a - TxTimeStamp_a
RxTime_a is the local timestamp of node B when receiving the PDM
packet. If the time difference Delta_t of the two ends is already
known, the calculation formula could be as follows.
Packet Delay [one-way] = RxTime_a - TxTimeStamp_a + Delta_t
Guo, Chen, and Chan. Expires September 10, 2009 [Page 17]
Internet-Draft BFD extensions for PM March 2009
For one-way PDM being dependent on the synchronization of clock/time
between the two systems, the synchronization of clock/time is
desired.
4.2.1 Two-way PDM
+-+-+ +-+-+
| A | | B |
+-+-+ +-+-+
Start T1 |---BFD PDM Request--->|TT1
T1'|<---BFD PDM Reply ----|TT1'
| |
T2 |---BFD PDM Packet --->|TT2
First Calculation T2'|<---BFD PDM Reply ----|TT2'
| . |
| . |
| . |
| |
Tn |---BFD PDM Packet --->|TTn
Nth Calculation Tn'|<---BFD PDM Reply ----|TTn'
| |
| |
Figure 7: Two-way Packet Delay measurement
Two-way PDM is a request-reply mode, which one system as the active
end initiates the PDM request packet, the other system acts as
passive end will send back a PDM reply packet when received the PDM
request packet. Then the active end will perform two-way packet
delay calculation. For the characters of this mode, BFD demand mode
is preferred. Figure 7 describes the operation flow.
When two-way PDM is enabled, node A as the active end will send BFD
PDM request packets with Packet Delay TLV to the other end, node B.
The same as the one-way mode, the local timestamp TxTimeStamp_a and
sequence MUST be included. When node B received a BFD PDM request
packet, it will reply by sending a PDM reply packet with PDM TLV
containing the timestamp and sequence copied from of the received
PDM request packet.
Once received the PDM reply packet, node A will perform packet delay
calculation. The formula is as follows.
Packet Delay [two-way] = RxTime_a - TxTimeStamp_a
Guo, Chen, and Chan. Expires September 10, 2009 [Page 18]
Internet-Draft BFD extensions for PM March 2009
RxTime_a is the timestamp of the active end receiving the PDM reply
packet from the passive end.
The other two additional timestamps in the packet delay TLV,
RxTimeStamp_p and TxTimeStamp_p, stand for the timestamps that the
passive end receiving the PDM request packet and sending the PDM
reply packet to the active end respectively, which could be used to
perform more precise two-way packet delay measurement. As an option,
if operator wants to take into account the processing time at the
node B, the two additional timestamps should be included in the PDM
reply packet by the passive end. Formula for calculation is bellow.
Packet Delay [two-way] = (RxTime_a - TxTimeStamp_a) -
(TxTimeStamp_p-RxTimeStamp_p)
Two-way PDM is relaxed for synchronization of clock. So if the
clocks are not practical to be synchronized between the two ends,
which may be a common scenario, two-way delay measurement mode could
be used.
6.3. Packet Delay variation Measurement
Packet delay variation measurement is based on the difference of
subsequent packet delay measurement. The Packet Delay Variation is
relaxed for synchronization of clock and could be calculated by the
formulas below.
Frame Delay Variation[one-way] = Frame Delay2 [one-way] - Frame
Delay1 [one-way]
Frame Delay Variation[two-way] = Frame Delay2 [two-way] - Frame
Delay1 [two-way]
7. Security Considerations
Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379]
apply to this document.
8. IANA Considerations
IANA is requested to assign two new TLVs for Performance Measurement.
The following numbers are suggested.
Value Meaning
6 Packet loss TLV
Guo, Chen, and Chan. Expires September 10, 2009 [Page 19]
Internet-Draft BFD extensions for PM March 2009
7 Packet delay TLV
9. Acknowledgments
The authors would like to thank Jian Li and Wei Cao for their
comments and help for preparing this document.
10. References
10.1. Normative References
[RFC 4377] Nadeau, T., et al., ''Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched (MPLS)
Networks'', RFC 4377, February 2006.
[RFC 4378] D. Allan, Ed., T. Nadeau, Ed.,'' A Framework for Multi-
Protocol Label Switching (MPLS) Operations and Management
(OAM)'', RFC 4378, February 2006.
[Y.1710] ITU-T Recommendation Y.1710, "Requirements for OAM
Functionality for MPLS Networks". November, 2002.
[Y.1731] ITU-T Y.1731 OAM functions and mechanisms for Ethernet
based networks. May, 2006.
[Y.1373/G.8114] ITU-T Recommendation Y.1373/G.8114, ''Operation &
maintenance mechanism for T-MPLS layer networks'',
[Y.1541] Network Performance Objectives for IP-Based Services.
[Y.Sup4] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for
T-MPLS OAM and considerations for the application of IETF
MPLS Technology.
10.2. Informative References
[BFD] Katz, D., et al., " Bidirectional Forwarding Detection ",
draft-ietf-bfd-base-08.txt, {work in progress}.
[BFD-VCCV] Nadeau, T., Pignataro, C., et al., " Bidirectional
Forwarding Detection (BFD) for the Pseudowire Virtual
Circuit Connectivity Verification (VCCV) ", draft-ietf-
pwe3-vccv-bfd-02, {work in progress}.
Guo, Chen, and Chan. Expires September 10, 2009 [Page 20]
Internet-Draft BFD extensions for PM March 2009
[MPLS-TP-OAM-REQ] Vigoureux, M., Wardet, D., Betts, M., "
Requirements for OAM in MPLS Transport Networks ", draft-
vigoureux-mpls-tp-oam-requirements-00.txt, {work in
progress}
[BFD-1HOP] Katz, D., Ward, D.,'' BFD for IPv4 and IPv6 (Single Hop)'',
draft-ietf-bfd-v4v6-1hop-08.txt, {work in progress}.
[BFD-MULTI] Katz, D., Ward, D.,'' BFD for Multihop Paths'', draft-
ietf-bfd-multihop-06.txt, {work in progress}.
[BFD-MPLS] Aggarwal, R., et al., ''BFD For MPLS LSPs '', draft-ietf-
bfd-mpls-07.txt, {work in progress}
Authors' Addresses
Xinchun Guo
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Email: guoxinchun@huawei.com
Mach(Guoyi) Chen
Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District
Beijing, 100085
P.R. China
Email: mach@huawei.com
Kwok Ho Chan
Huawei Technologies
125 Nagog Park
Acton, MA 01720
USA
Email: khchan@huawei.com
Guo, Chen, and Chan. Expires September 10, 2009 [Page 21]
