One document matched: draft-wang-ccamp-latency-te-metric-01.txt
Differences from draft-wang-ccamp-latency-te-metric-00.txt
Network Working Group Q. Wang
Internet-Draft X. Fu
Intended status: Standards Track ZTE Corporation
Expires: April 28, 2011 Oct 25, 2010
GMPLS extensions to communicate latency as a TE performance metric
draft-wang-ccamp-latency-te-metric-01
Abstract
Latency is such requirement that must be achieved according to the
SLA signed between customers and service providers, so mechanism is
needed to collect, compute and identify the latency by signaling and
routing protocol.
This document describes the requirement and method to compute and
identify the latency by control plane in today's network which is
consisted of packet transport network and optical transport network
in order to meet the latency SLA of the customer. This document also
describes RSVP-TE signaling and OSPF routing extensions needed to
support the computation and identification of latency. These
extensions are intended to advertise and convey the information of
node latency and link latency as TE performance metric.
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 April 28, 2011.
Copyright Notice
Copyright (c) 2010 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
Wang & Fu Expires April 28, 2011 [Page 1]
Internet-Draft latency as a TE performance metric Oct 2010
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
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. List of Acronyms . . . . . . . . . . . . . . . . . . . . . 5
3. Analysis of the Latency Measurement Mechanism . . . . . . . . 5
3.1. Support of SLA . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Latency Value . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Latency of Server Layer Network . . . . . . . . . . . . . 7
3.4. Role of the Control Plane . . . . . . . . . . . . . . . . 7
3.5. Impact of the Change of Link Latency . . . . . . . . . . . 8
4. A New Latency Measurement Mechanism . . . . . . . . . . . . . 8
4.1. Advertisement of the Latency Value . . . . . . . . . . . . 8
4.2. Latency Collection and Verification . . . . . . . . . . . 9
5. Signaling and Routing Extensions to Support Latency
Measurement . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Routing Extensions to Support the Advertisement of
Latency . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Signaling Extensions to Support the Latency Measurement . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Wang & Fu Expires April 28, 2011 [Page 2]
Internet-Draft latency as a TE performance metric Oct 2010
1. Introduction
In a network, latency, a synonym for delay, is an expression of how
much time it takes for a packet of data to get from one designated
point to another. In some usages, latency is measured by sending a
packet that is returned to the sender and the round-trip time is
considered the latency. In this document, we refer to the former
expression.
In many cases, latency is a sensitive topic. For example, two stock
exchanges, one in Beijing, which is a city of north China and another
in Shenzhen, which is a city of south China. Both of them need to
synchronize with each other. A little change may result in large
loss. So something SHOULD be assured that the network path latency
MUST be limited to a value lower than the upper limit. SLA contract
which includes the requirement of latency is signed between service
providers and customers. In the future, latency demand will be
needed by more and more customers.
Measurement mechanism of link latency has been defined in many
technologies. For example, the measurement mechanism of link latency
has been provided in ITU-T [G.8021] and [Y.1731] for Ethernet. The
link transit latency between two Ethernet equipments can be measured
by using this mechanism. Similarly, overhead byte and measurement
mechanism of latency has been provided in OTN (i.e., ITU-T [G.709]).
In order to measure the link latency between two OTN nodes, PM&TCM
which include Path Latency Measurement field and flag used to
indicate the beginning of measurement of latency is added to the
overhead of ODUk. The detailed measurement mechanism of link latency
is out of scope of this document. You can refer to ITU-T G.709 for
more messages. Technologies that do not support the measurement of
latency SHOULD be developed to allow the measurement of link latency
in scenario similar to the above. This is out of scope of this
document. Node latency can also be recorded at each node by
recording the process time at the beginning and at the end. More
detail of the node latency is described in section 3.2.
Current operation and maintenance mode of latency measurement is high
in cost and low in efficiency. Only after the path needed by the
customers' business is determined, signal can be sent to detect
whether the latency of the path fit the requirement of the customers.
If not, another path SHOULD be determined by the ingress node until
one can. So a low cost and high efficiency latency measurement
method SHOULD be provided in order to support the SLA. However, the
control plane does not provide latency measure mechanism. A new
method is provided that the node latency, link latency and latency
variation can be collected by control plane from the transport plane.
Then node latency, link latency values and latency variation can be
Wang & Fu Expires April 28, 2011 [Page 3]
Internet-Draft latency as a TE performance metric Oct 2010
used by service provider through control plane to provide a path
correspond with the customers' requirement. As there is demand from
the customer, this method can be used to select a path correspond
with customers' latency demand. In this document, link latency
refers to the latency of the link between two neighbor nodes or a FA-
LSP.
This document describes the requirement and method to compute and
identify the latency by control plane in today's network which is
consisted of packet transport network and optical transport network
in order to meet the latency SLA of the customer. This document also
describes RSVP-TE signaling and OSPF routing extensions needed to
support the computation and identification of latency. Latency can
be divided into two types as described above: node latency which is
provided by the node as a result of process time at each node and
link latency as a result of packet traverse between two neighbor
nodes or a FA-LSP. Latency variation is also a parameter that is
used to indicate the variation range of the latency value.
Extensions are also intended to advertise and convey the information
of node latency, link latency and latency variation as TE performance
metric.
[RFC4203] details the OSPF extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS). In order to support the
advertisement of the attributes of the node latency, link latency and
latency variation by routing, extensions SHOULD be made to [RFC4203]
in this document. Thus ingress node that is responsible for the
creation of the path will have a good knowledge of the latency of the
path.
[RFC3473] details the Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions. Extensions SHOULD be made to [RFC3473] to
collect the node, link latency and latency variation along the path,
so egress node can determine whether such a path is adaptive. This
extensions is not necessary unless there is a need.
1.1. 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 [RFC2119].
2. Terminology
The reader is assumed to be familiar with the terminology in
[RFC3473] and [RFC4203].
Wang & Fu Expires April 28, 2011 [Page 4]
Internet-Draft latency as a TE performance metric Oct 2010
Frame Delay:
The definition of Frame Delay in ITU-T Y.1731 can be seen below.
Frame Delay can be specified as round-trip delay for a frame, where
Frame Delay is defined as the time elapsed since the start of
transmission of the first bit of the frame by a source node until the
reception of the last bit of the loop backed frame by the same source
node, when the loop back is performed at the frame's destination
node.
Frame Delay Variation:
The definition of Frame Delay in ITU-T [Y.1731] can be seen below.
Frame Delay Variation is a measure of the variations in the Frame
Delay between a pair of service frames.
Path Monitoring & Tandem Connection Monitoring:
Path Monitoring & Tandem Connection Monitoring is a field contained
in [G.709] OTN ODUk overhead, which can be used to support the
measurement of latency between two OTN nodes.
Service Level Agreement:
A service level agreement is a part of a service contract where the
level of service is formally defined between service providers and
customers.
2.1. List of Acronyms
FD: Frame Delay
FDV: Frame Delay Variation
PM&TCM: Path Monitoring & Tandem Connection Monitoring
SLA: Service Level Agreement
3. Analysis of the Latency Measurement Mechanism
As described in the Introduction section, latency is sensitive in
many cases like finance, storage. A little frame delay may result in
large loss. So network latency values MUST be strictly limited to a
value lower than the upper limit described in the SLA. Latency
measurement mechanism is important to certain customers. However,
the control plane does not provide latency measure mechanism. A
method is provided that the node latency, link latency and latency
variation can be collected by control plane from the latency
measurement of the transport plane. Then node latency, link latency
values and latency variation can be used by service provider through
control plane to provide a path correspond with the customers'
demand. In this document, link latency refers to the latency of the
link between two neighbor nodes or a FA-LSP. This section analyzes
latency support for SLA contract signed between customers and
Wang & Fu Expires April 28, 2011 [Page 5]
Internet-Draft latency as a TE performance metric Oct 2010
providers, analysis of the mechanism of latency measurement, latency
of the server layer network and role of the control plane in this new
latency measurement mechanism.
3.1. Support of SLA
In today's network (e.g., DWDM), latency measurement is required by
many service providers because of the demand from the customers.
Latency is especially important for the customers who provide service
like finance, storage. As a result of the demand, SLA contract which
includes the demand of latency is signed between service providers
and customers. According to the definition in section 2, SLA (i.e.,
Service Level Agreement) is a part of a service contract where the
level of service is formally defined between service providers and
customers. Service providers MUST provide accurate latency
measurement result to the customers per SLA levels. Latency to
different customers can be different per SLA levels.
However, current operation and maintenance mode of latency
measurement through transport plane is high in cost and low in
efficiency. Only after the path needed by the customers' business is
determined, signal can be sent to detect whether the latency of the
path fit the requirement of the customers. A new method described in
this document is provided to support a low cost and high efficiency
latency measurement mechanism in order to support the SLA. This can
be seen in the 4th section and 5th section.
3.2. Latency Value
The mechanism of latency measurement can be sorted into two types.
In order to monitor the performance, pro-active latency measurement
is required. Generally, every 15 minutes or 24 hours, the value of
FD and FDV SHOULD be collected. Similarly, on demand latency
measurement is required due to the goal of maintenance. This can be
done every fixed time interval (e.g., 5 minutes or 1 hour).
As described in [CL-REQ], when a traffic flow moves from one
component link to another in the same composite link between a set of
nodes (or sites), it MUST be processed in a minimally disruptive
manner. When a traffic flow moves from a current link to a target
link with different latency, reordering can occur if the target link
latency is less than that of the current and clumping can occur if
target link latency is more than that of the current. Therefore, the
solution SHALL provide a means to indicate that a traffic flow shall
select a component link with the minimum latency value and a maximum
acceptable latency value.
Similarly, the value of latency is not fixed because of different
Wang & Fu Expires April 28, 2011 [Page 6]
Internet-Draft latency as a TE performance metric Oct 2010
signal process technology (The packet transport network use
statistical multiplexing and the optical transport network use time
division multiplex). For example, in statistical multiplexing
business, latency for every business may be different because of the
existence of buffering and priority. At this time, average latency
value is needed when refer to node latency. Average latency value of
node can be derived through the computation of the node or management
plane configuration.
latency varation is also needed in the case the latency value of, for
example, average latency value's variation range.
Measurement mechanism of link latency has been defined in many
technologies like Ethernet, OTN. You can refer to ITU-T [G.8021],
[Y.1731] and [G.709] for more information.
3.3. Latency of Server Layer Network
When a LSP traverses a server layer FA-LSP, the latency information
of the FA-LSP SHOULD be provided by signaling protocol message if
needed. Extension to the current signaling protocol is done to carry
the latency information of the server layer FA-LSP. This is
described in section 4 and section 5.
The boundary nodes of the FA-LSP SHOULD be aware of the latency
information of this FA-LSP (i.e., minimum latency, maximum latency,
average latency). If the latency information of the FA-LSP changes,
the ingress node of the FA-LSP will receive the TE link information
advertisement including the latency value which is already changed,
then it will compute the total latency value of the FA-LSP again. If
this value changes, the client layer of the FA-LSP MUST also be
notified about the total value of the latency.
The ingress node or egress node of the FA-LSP can advertise the total
value of the latency to the client layer nodes connecting to the
ingress node or egress node through signaling protocol message (e.g.,
notify message or refresh message). If the FA-LSP is able to form a
routing adjacency and/or as a TE link in the client network, the
value of the FA-LSP can be used as TE link metric and advertised into
the client layer routing instances or PCE.
3.4. Role of the Control Plane
Current mechanism of latency measurement is provided by transport
plane instead of control plane. The latency information between two
specified nodes will be detected if there is latency demand of the
path between the two nodes. This is low in efficiency and high in
cost if the latency information does not correspond with the
Wang & Fu Expires April 28, 2011 [Page 7]
Internet-Draft latency as a TE performance metric Oct 2010
customers' demand.
A new method of latency measurement mechanism is provided by
collecting the node latency value, link latency value between two
neighbor nodes or a FA-LSP and latency variation, then these values
is provided to the control plane. Control plane can compute a path
correspond with customers' demand with these latency values.
3.5. Impact of the Change of Link Latency
If the link latency of a LSP which have a latency value corresponds
with customers' demand changes, the ingress node or PCE will be aware
of the latency value change in the network. Total latency value of
the LSP affected by the latency value change will be re-computed
through the ingress node or PCE. Client service SHOULD be switched
to a new LSP which have a latency value corresponds with customers'
demand if current changed latency value is invalid. This is much
like the recovery, but not recovery. All the LSPs affected by this
latency change may not be rerouted to find appropriate LSPs if they
still have appropriate latency values. All the LSPs affected will be
rerouted to find a recovery path if there is a link failure.
As a result of the change of link latency in the LSP, current LSP may
be frequently switched to a new LSP with a appropriate latency value.
In order to avoid this, solution SHOULD indicate the switchover of
the LSP according to maximum acceptable value of the customers.
4. A New Latency Measurement Mechanism
This new latency measurement can be divided into two phases. The
first phase is the advertisement of the latency information by
routing protocol, including node latency, link latency between two
neighbor nodes or a FA-LSP and latency variation, so every node in
the network can be aware of the latency of every node and link. The
second phase is the latency collection and verification along the
path from the ingress node to the egress node by signaling protocol,
so an adaptive LSP can be found out and verified.
4.1. Advertisement of the Latency Value
As described in the introduction section, a node in the packet
transport network or optical transport network can detect link
latency value which has connection with it. Also the node latency
can be recorded at every node. Then these link latency values of the
neighbor nodes, node latency and latency variation is notified to the
control plane. The control plane instances then advertise these link
latency values, node latency values and latency variation as
Wang & Fu Expires April 28, 2011 [Page 8]
Internet-Draft latency as a TE performance metric Oct 2010
attributes of the TE link to the other nodes in the routing domain or
PCE by routing protocol. If any latency values change, then the
change MUST be notified to the control plane instances, then
advertise by routing protocol in the routing domain or to the PCE.
As a result, control plane instances and PCE can have every node
latency values, link latency values and latency variation in the
network.
4.2. Latency Collection and Verification
When the PCE receives the request which indicates the demand of
latency, PCE can compute a path which satisfies customers' latency
demand with the node latency values, link latency values and latency
variation in the network. The ingress node initializes the creation
of the LSP with path signaling message which includes the latency
demand parameter. The path signaling message collects the node
latency value, link latency value and latency variation along the
path. When the path signaling message reaches the egress node, the
egress node can verify whether the value of the latency is applicable
by comparing the LSP latency with the latency demand parameter
carried in the path message. Similarly, when egress node returns
recv signaling message to ingress node, node latency values, link
latency values and latency variation will also be gathered in the
reverse direction. The ingress node verifies whether the latency
values from the egress node to the ingress node is applicable.This
extensions is not necessary unless there is a need.
When a LSP traverses a server layer FA-LSP, the latency information
of the FA-LSP is advertised by routing protocol and carried in the
signaling message. The latency information of the server layer FA-
LSP can be carried in the ERBO object which is defined in
[draft-fuxh-ccamp-boundary-explicit-control-ext]. Region boundaries
carried in ERBO contain one pair or multiple pair of nodes. One pair
of boundary nodes indicates the head node and the end node of the FA-
LSP (i.e., the region boundary). The latency values information of
the FA-LSP between two boundary nodes is carried in the signaling
message directly behind a pair of boundary nodes in the ERBO.
Ingress node will re-compute the total latency value of the FA-LSP if
the total latency value of the FA-LSP changes. The latency value of
the FA-LSP SHOULD be announced to the client layer of the FA-LSP,
also advertised in the routing domain.
5. Signaling and Routing Extensions to Support Latency Measurement
Extensions SHOULD be done to existing OSPF-TE routing protocol and
RSVP-TE routing protocol, in order to support the advertisement, the
collection and the verification of the latency values. In this
Wang & Fu Expires April 28, 2011 [Page 9]
Internet-Draft latency as a TE performance metric Oct 2010
section, routing extensions and signaling extensions will be
described.
5.1. Routing Extensions to Support the Advertisement of Latency
Some extensions to the existing OSPF-TE routing protocol to support
the advertisement of the node latency value, link latency and latency
variation value in the routing domain or to the PCE as TE metric.
OSPF-TE routing protocol can be used to carry latency information by
adding a sub-TLV to the TE link which is defined in [RFC4203]. The
latency value can be used as constraint for routing computation and
as a factor impacting the node and link performance.
As defined in [RFC3630] and [RFC4203], the top-level TLV can take one
of two values (1) Router address or (2) Link. Node latency sub-TLV
and link latency sub-TLV can be added behind the top-level TLV. The
link latency sub-TLV has the same format as node latency TLV. They
both include these parameters like minimum latency value, minimum
latency variation value, maximum latency value, maximum latency
variation value, average latency value, average latency variation
value. The format of the sub-TLV can be seen below.
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(IANA) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Latency Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Latency Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average Latency Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency Variation Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the sub-TLV
- Minimum Latency Value: a value indicates the boundary of the node
latency or link latency along with maximum latency value.
- Maximum Latency Value: a value indicates the boundary of the node
latency or link latency along with maximum latency value.
Wang & Fu Expires April 28, 2011 [Page 10]
Internet-Draft latency as a TE performance metric Oct 2010
- Average Latency Value: a value indicates the average of the node
latency or link latency.
- Latency Variation Value: a value indicates the variation range of
the minimum latency value, maximum latency value or average
latency value.
5.2. Signaling Extensions to Support the Latency Measurement
Extensions SHOULD also be done to the RSVP-TE signaling protocol to
support the collection and verification of the latency measurement.
This can be achieved base on the extension to the RRO which is
defined in [RFC3209] by adding an interface ID (i.e., IP Address) or
interface identifier defined in [RFC3477], then adding the sub-TLV
which has the same format with that described above. When a node
receives the path message, node latency value, link latency value and
latency variation along the path which has correlation to the node
will be added behind the interface identifier and node ID sub-object.
At the same time, the latency values requirement from the ingress
node to the egress node have been added into the TE metric TLV. When
the egress node receives the path message, the latency value of the
LSP can be compute by the node latency value, link latency value and
latency variation carried behind RRO. If the total latency value
does not meet the requirement of the customer, patherr message SHOULD
be created and return to the ingress node. Recv message can be used
to collect and verify the latency information in the reverse
direction in the same way.
The signaling format of the sub-TLV has the same format as that
described in the section 5.1. This format can also been used behind
a pair of boundary nodes which are carried in ERBO to indicate the
latency information of the FA-LSP if there are requirement of the
server layer.
6. Security Considerations
TBD
7. IANA Considerations
TBD
8. References
Wang & Fu Expires April 28, 2011 [Page 11]
Internet-Draft latency as a TE performance metric Oct 2010
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
8.2. Informative References
[CL-REQ] C. Villamizar, "Requirements for MPLS Over a Composite
Link", draft-ietf-rtgwg-cl-requirement-02 .
[G.709] ITU-T Recommendation G.709, "Interfaces for the Optical
Transport Network (OTN)", December 2009.
Authors' Addresses
Qilei Wang
ZTE Corporation
No.68 ZiJingHua Road,Yuhuatai District
Nanjing 210012
P.R.China
Email: wang.qilei@zte.com.cn
URI: http://wwwen.zte.com.cn/
Wang & Fu Expires April 28, 2011 [Page 12]
Internet-Draft latency as a TE performance metric Oct 2010
Xihua Fu
ZTE Corporation
West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District
Xi An 710065
P.R.China
Phone: +8613798412242
Email: fu.xihua@zte.com.cn
URI: http://wwwen.zte.com.cn/
Wang & Fu Expires April 28, 2011 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 03:05:36 |