Network Working Group Q. Wang Internet-Draft X. Fu Intended status: Standards Track ZTE Corporation Expires: April 21, 2011 Oct 18, 2010 GMPLS extensions to communicate latency as a TE performance metric draft-wang-ccamp-latency-te-metric-00 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 21, 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 21, 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 4. A New Latency Measurement Mechanism . . . . . . . . . . . . . 8 4.1. Advertisement of the Latency Value . . . . . . . . . . . . 8 4.2. Latency Collection and Verification . . . . . . . . . . . 8 5. Signaling and Routing Extensions to Support Latency Measurement . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Routing Extensions to Support the Advertisement of Latency . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Signaling Extensions to Support the Latency Measurement . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Wang & Fu Expires April 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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. 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 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 Wang & Fu Expires April 21, 2011 [Page 8] Internet-Draft latency as a TE performance metric Oct 2010 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 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 Wang & Fu Expires April 21, 2011 [Page 9] Internet-Draft latency as a TE performance metric Oct 2010 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Latency Value | Latency Variation Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Latency Value | Latency Variation 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. - 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 Wang & Fu Expires April 21, 2011 [Page 10] Internet-Draft latency as a TE performance metric Oct 2010 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 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. Wang & Fu Expires April 21, 2011 [Page 11] Internet-Draft latency as a TE performance metric Oct 2010 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/ 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 21, 2011 [Page 12]