Coloring based IP Flow Performance Measurement Framework
draft-chen-coloring-based-ipfpm-framework-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 "Expired".
|
|
|---|---|---|---|
| Authors | Mach Chen , Hongming Liu, Yuanbin Yin | ||
| Last updated | 2013-02-18 | ||
| 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-chen-coloring-based-ipfpm-framework-00
Network Working Group M. Chen
Internet-Draft H. Liu
Intended status: Informational Y. Yin
Expires: August 21, 2013 Huawei
February 17, 2013
Coloring based IP Flow Performance Measurement Framework
draft-chen-coloring-based-ipfpm-framework-00
Abstract
By setting one unused bit of the IP header of packets to "color" the
packets into different color blocks, it naturally gives a way to
measure the real packet loss and delay without inserting any extra
OAM packets. This is called coloring based IP performance
measurement. This document specifies a framework and protocol for
this "coloring" based IP performance measurement.
Requirements Language
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].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 21, 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
Chen, et al. Expires August 21, 2013 [Page 1]
Internet-Draft Colouring based IP FPM Framework February 2013
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview and Concept . . . . . . . . . . . . . . . . . . . . . 4
4. Reference Model and Functional Components . . . . . . . . . . 5
4.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 5
4.2. Measurement Control Point . . . . . . . . . . . . . . . . 6
4.3. Data Collecting Point . . . . . . . . . . . . . . . . . . 7
4.4. Target Logical Port . . . . . . . . . . . . . . . . . . . 8
5. Colouring based Performance Measurement Protocol . . . . . . . 8
5.1. Common Message Header . . . . . . . . . . . . . . . . . . 8
5.2. Open Message . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. KeepAlive Message . . . . . . . . . . . . . . . . . . . . 9
5.4. Configure Message . . . . . . . . . . . . . . . . . . . . 9
5.5. Report Message . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Chen, et al. Expires August 21, 2013 [Page 2]
Internet-Draft Colouring based IP FPM Framework February 2013
1. Introduction
Performance Measurement (PM) is an important tool that can not only
provide Service Level Agreement (SLA) verification but facilitate in
trouble shooting (e.g., fault localization or fault delimitation) and
network visualization.
There are two types of performance measurement: one is active
performance measurement, and the other is passive performance
measurement.
In active performance measurement the receiver measures the injected
packets to evaluate the performance of a path. The active
measurement measures the performance of the extra injected packets,
the rate, numbers and interval of the injected packets will largely
affect the accuracy of the results. In addition, it also requires
that the injected packets have to follow the same path as the real
traffic; this normally cannot be guaranteed in the pure IP network.
The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way
Active Measurement Protocol (TWAMP) [RFC5357] are tools to enable
active performance measurement.
In passive performance measurement, no artificial traffic is injected
into the flow and measurements are taken to record the performance
metrics of the real traffic. The Multiprotocol Label Switching
(MPLS) PM protocol [RFC6374] for packet loss is an example of passive
performance measurement. By periodically inserting auxiliary
Operations, Administration, and Maintenance (OAM) packets, the
traffic is delimited by the OAM packets into consecutive blocks, and
the receivers count the packets and calculate the packets loss each
block.
But, when the OAM channel is in-band, solutions like [RFC6374] are
not pure passive measurement as the OAM packets are inserted into the
data stream. Furthermore because solutions like [RFC6374] depend on
the fixed positions of the delimiting OAM packets for packets
counting, they are vulnerable to out-of-order arrival of packets.
This could happen particularly with out-of-band OAM channels, but
might also happen with in-band OAM because of the presence of
multipath forwarding within the network. Out of order delivery of
data and the delimiting OAM can give rise to inaccuracies in the
performance measurement figures. The scale of these inaccuracies
will depend on data speeds and the variation in delivery, but with
out-of-band OAM, this could result in significant differences between
real and reported performance.
This document describes a mechanism where data packets are marked or
"colored" so that they form blocks of data. No additional delimiting
Chen, et al. Expires August 21, 2013 [Page 3]
Internet-Draft Colouring based IP FPM Framework February 2013
OAM is needed and the performance can be measured in-service without
the insertion of additional traffic. Furthermore, because coloring
based IP performance measurement does not require extra OAM packets
for traffic delimitation, it can be used in situations where there is
packets re-ordering. This document specifies a framework and
protocol for the "coloring" based IP performance measurement.
2. Terminology
SLA: Service Level Agreement
OAM: Operations Administration and Maintenance
MCP: Measurement Control Point
MP: Measurement Point
DCP: Data Collecting Point
TLP: Target Logical Port
MPLS: Multiprotocol Label Switching
CSG: Cell Site Gateway
RNC: Radio Network Controller
RSG: RNC Site Gateway
3. Overview and Concept
The concept of "coloring" IP packets for performance measurement is
described in [I-D.tempia-opsawg-p3m]. By "coloring" the packets of a
specific IP flow to different colors, it naturally splits the IP flow
into deferent consecutive blocks.
For packet loss measurement, there are two ways to color packets:
fixed packet numbers or fixed time period for each color block. This
document only talks about the way of fixed time period. The sender
and receiver nodes count the transmitted and received packets/octets
based on each color block. By collecting and comparing the
transmitted and received packets/octets, it can easily detect whether
there is packet loss and how many packets/octets get lost.
For packet delay measurement, there are two solutions. One is
similar to packet loss, it still colors the IP flow to different
Chen, et al. Expires August 21, 2013 [Page 4]
Internet-Draft Colouring based IP FPM Framework February 2013
color blocks and uses the time when color changing as the reference
time for delay calculation. This solution requires that there must
not be any out-of-order packets, otherwise, the result will not be
accurate. Because it uses the first packet of each color block for
delay measurement, if there is packet reordering, the first packet of
each block at the sender will be probably different from the first
packet of the block at the receiver. The other way is to
periodically color a single packet of the IP flow. Within a time
period, there is only one packet can be colored. The sender records
the timestamp when the colored packet is transmitted, the receiver
records the timestamp when detecting the colored packet. With the
two timestamps, the packet delay can be computed.
To make the above solutions work, two conditions are required. The
first one is that there have to be a way to collect the packet counts
and timestamps from the senders and receivers to a centralized
calculation element. The second is that the centralized calculation
element has to know what exactly a pair of packet counts(one from the
sender and the other is from the receiver) are based on the same
color block and a pair of timestamps (one from the sender and the
other is from the receiver) are based on the same colored packet.
4. Reference Model and Functional Components
4.1. Reference Model
An Multipoint-to-Multipoint (MP2MP) reference model (as shown in
Figure 1) is introduced in this document. For a specific IP flow,
there may be one or more upstream and downstream Measurement Points
(MPs). An IP flow can be identified by the Source IP (SIP) and
Destination IP (DIP) addresses, and it may combine the SIP and DIP
with any or all of the Protocol number, the Source port, the
Destination port, and the Type of Service (TOS) to identify an IP
flow.
An MP is a network node. From the measurement point of view, it
consists of two parts (as shown in Figure 2): Data Collecting Point
(DCP), and Target Logical Port (TLP). For an MP, there is only one
DCP and may be one or more TLPs. The Measurement Control Point (MCP)
is a centralized calculation element, MPs periodically report their
measurement data to the MCP for final performance calculation. The
report protocol is defined Section 5 of this document.
The reason for choosing MP2MP model is that it can satisfy all the
scenarios that include Point-to-Point (P2P), Point-to-Multipoint
(P2MP), Multipoint-to-Point (MP2P), and MP2MP. P2P scenario is
obvious and can be used anywhere. P2MP and MP2P are very common in
Chen, et al. Expires August 21, 2013 [Page 5]
Internet-Draft Colouring based IP FPM Framework February 2013
mobile backhaul networks. For example, a Cell Site Gateway (CSG)
multi-homing to two Radio Network Controller (RNC) Site Gateways
(RSGs) is a typical network design. When there is a failure, there
is a requirement to monitor the flows between the CSG and the two
RSGs hence to determine whether the fault is in the transport network
or in the wireless network(this is normally called "fault
delimitation"). This is especially useful in the situation where the
transport network belongs to one service provider and wireless
network belongs to other service providers.
+-----+
+------| MCP |------+
| +-----+ |
+-----+ | +---/ \---+ | +-----+
| MP1 |---+ | | +---| MP3 |
+-----+ | | +-----+
+-----+ | | +-----+
| MP2 |------+ +------| MP4 |
+-----+ +-----+
Figure 1: MP2MP based Model
+----------------------+
| +--------+ |
| | DCP | | Control Plane
| +--------+ |
----------|-----/----------\-----|--------------
| +--+--+ +--+--+ |
| | TLP1| | TLP2| | Data plane
| +-----+ +-----+ |
+----------------------+
Figure 2: Measurement Point
4.2. Measurement Control Point
The MCP is responsible for calculating the final performance metrics
according to the received measurement data from the MPs (actually
from the DCPs). For packet loss, based on each color block, the
difference between the total counts received from all upstream MPs
and the total counts received from all downstream MPs are the lost
packet numbers. The MCP must make sure that the counts from the
upstream MPs and downstream MPs are related to the same color block.
For packet delay (e.g., one way delay), the difference between the
timestamps from the downstream MP and upstream MP is the packet
delay. Similarly to packet loss, the MCP must make sure the two
timestamps are based on the same colored packet.
Chen, et al. Expires August 21, 2013 [Page 6]
Internet-Draft Colouring based IP FPM Framework February 2013
This document introduces a Period Number (PN) based synchronization
mechanism to help the MCP to determine whether any two or more packet
counts (from distributed MPs) are related to the same color block or
any two timestamps are related to the same colored packet. The PN is
generated each time a DCP reads the packet counts and timestamps from
the TLP, and is equal to the modulo of the local time (when the
counts and timestamps are read) and the interval of the color time
period. Each packet count and timestamp has a PN when reported to
the MCP, and the same PN means that they are related to the same
color block or colored packet. This requires that the upstream and
downstream MPs having a certain time synchronization capability
(e.g., supporting the Network Time Protocol (NTP) [RFC5905], or the
IEEE 1588 Precision Time Protocol (PTP) [IEEE1588].) and assumes that
the upstream and downstream MPs have already time synchronized.
Since is the intention to measure packet delay, this requirement for
time synchronization is already present.
4.3. Data Collecting Point
The DCP is responsible for periodically collecting the measurement
data from the TLPs and for reporting the data to the MCP. In
addition, when to change the color, when to color a packet (for
packet delay measurement), and when to read the packet counts and
timestamps are also controlled by DCP. Each DCP will maintain two
timers, one (C-timer, used at upstream DCP) is for color changing,
the other (R-timer, used at downstream DCP) is for reading the packet
counts and timestamps. The two timers have the same time interval
but are started at different times. A DCP can be either an upstream
or a downstream DCP: the role is specific to an IP flow. For a
specific IP flow, the upstream DCP will change the color and read the
packet counts and timestamps when the C-timer expires, the downstream
DCP just reads the packets counts and timestamps when the R-timer
expires. In order to allow for a certain degree of packets re-
ordering, the R-timer should be started later than a defined period
of time after the C-timer is started (e.g., 1/3 or 2/3 T, where T is
the interval of the C-timer). It recommends that: for packet loss
measurement, the R-timer should be started at 1/3 T after the C-Timer
is started, and for packet delay measurement, the R-timer should be
started at 2/3 T after the C-Timer is started.
To make the implementation simple, the C-timer should be started at
the beginning of each time period. This document recommends the
implementation to support at least these time periods (1s, 10s, 1min,
10min and 1h). So, if the time period is 10s, the C-timer should be
started at the time of any multiples of 10 in seconds (e.g., 0s, 10s,
20s, etc.), then the R-timer should be started, for example, at the
time of T+1/3 or 2/3 T. With this method, each DCP can independently
start its C-timer and R-timer given that the clocks have been
Chen, et al. Expires August 21, 2013 [Page 7]
Internet-Draft Colouring based IP FPM Framework February 2013
synchronized.
4.4. Target Logical Port
The TLP is a logical entity that actually executes the final
measurement actions (e.g., colors the packets, counts the packets,
records the timestamps, etc.). Normally, a physical interface
corresponds to a TLP, and the TLP resides in the data plane. For a
measurement instance (corresponding to an IP flow), a TLP will
maintain a pairs of packet counters and a timestamp counter for each
color block. One packet counter is for counting packets and the
other is for counting octets.
5. Colouring based Performance Measurement Protocol
This section is a preliminary documentation of CPMP. More details
will be supplied in a future version of this document.
The Coloring-based Performance Measurement Protocol (CPMP) is defined
for communication between DCP and MCP. An MCP may use it to enable/
disable a measurement instance on DCPs, and DCPs use it to
periodically report measurement data to the MCP. The CPMP uses TCP
as the transport protocol, a dedicated TCP port is required. The MCP
listens on the port and accept the connect request from DCPs. So,
DCPs must know where the MCP is, this could be done by configuration
when creating a measurement instance.
5.1. Common Message Header
There are 4 messages defined in this document, which include Open
Message, KeepAlive Message, Configure Message and Report Message.
Each message has a common header 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Rev | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Open Message
After a TCP session between a DCP and MCP is established, the Open
Message is the first message sent by the MCP to the DCP or the DCP to
the MCP hence to establish a CPMP session. The format of Open
Message is as follows:
Chen, et al. Expires August 21, 2013 [Page 8]
Internet-Draft Colouring based IP FPM Framework 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Res | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time | Keep Alive |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More detail in the future version.
5.3. KeepAlive Message
A Keepalive message is sent by a DCP or a MCP in order to keep the
CPMP session in active state. The Keepalive message is also used in
response to an Open message to acknowledge that an Open message has
been received and that the CPMP session characteristics are
acceptable.
The format of Keepalive message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Rev | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
More detail in the future version.
5.4. Configure Message
Configure Message is a message that a MCP uses to configure
parameters of the measurement instances on DCP and to enable/disable
the instances.
Chen, et al. Expires August 21, 2013 [Page 9]
Internet-Draft Colouring based IP FPM Framework 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|R| Rev | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Configure TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configure Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Configure TLV
More detail in the future version.
5.5. Report Message
Report Message is a message that a DCP uses it to report measurement
data to MCP.
Chen, et al. Expires August 21, 2013 [Page 10]
Internet-Draft Colouring based IP FPM Framework 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Rev | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DCP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MCP-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Instance TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Report Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Period Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count1(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count2(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp(cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure, Instance TLV
More detail in the future version.
6. IANA Considerations
TBD.
Chen, et al. Expires August 21, 2013 [Page 11]
Internet-Draft Colouring based IP FPM Framework February 2013
7. Security Considerations
TBD.
8. Acknowledgements
The authors would like to thank Adrian Farrel for his review,
suggestion and comments to this document.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.tempia-opsawg-p3m]
Bonda, A., Capello, A., Cociglio, M., and L. Castaldelli,
"A packet based method for passive performance
monitoring", draft-tempia-opsawg-p3m-02 (work in
progress), July 2012.
[IEEE1588]
IEEE, "1588-2008 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", March 2008.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
Chen, et al. Expires August 21, 2013 [Page 12]
Internet-Draft Colouring based IP FPM Framework February 2013
Authors' Addresses
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
Hongming Liu
Huawei
Email: liuhongming@huawei.com
Yuanbin Yin
Huawei
Email: yinyuanbin@huawei.com
Chen, et al. Expires August 21, 2013 [Page 13]