Network Working Group Y. Jiang Internet-Draft X. Liu Intended status: Informational Huawei Expires: April 2017 October 31, 2016 Gap Analysis of Deterministic Latency Networks draft-jiang-dln-gap-analysis-00 Abstract Deterministic latency network (DLN) is needed to provide guaranteed deterministic latency for use cases such as Cloud VR/Gaming and etc, especially for latency-critical traffic. This document analyzes the gaps in the existing IETF work on fulfilling the control plane and measurement needs of DLN. 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 April 31, 2013. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Jiang and et al Expires April 31, 2017 [Page 1] Internet-Draft DLN Gap Analysis October 2016 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 .............................................. 2 1.1. Conventions used in this document ...................... 2 1.2. Terminology ............................................ 2 2. Related Standardization Work in the IETF .................. 3 2.1. Work in the IPPM WG .................................... 3 2.2. Work in the MPLS WG .................................... 4 2.3. Work in the Control Protocols .......................... 5 3. Discussions ............................................... 5 4. Security Considerations ................................... 6 5. IANA Considerations ....................................... 6 6. References ................................................ 6 6.1. Informative References ................................. 6 7. Acknowledgments ........................................... 7 1. Introduction Deterministic latency network (DLN) is needed to provide guaranteed deterministic latency for use cases such as Cloud VR/Gaming and etc, especially for latency-critical traffic. This document analyzes the gaps in the existing IETF work on fulfilling the control plane and measurement needs of DLN. 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]. 1.2. Terminology NTP Network Time Protocol PHB per-hop behavior [Page 2] Internet-Draft DLN Gap Analysis October 2016 2. Related Standardization Work in the IETF 2.1. Work in the IPPM WG The IPPM Work Group has developed quite a lot of RFCs which specify standard metrics including quality, performance and reliability that can be used for the IP services. These protocols are usually implemented as software modules, and they rely on IP and TCP protocol stacks, as well as elements of the Network Time Protocol (NTP). A One-way Delay Metric for IPPM [RFC2679] is defined for packets across Internet paths based on notions introduced in the IPPM framework [RFC2330] with detailed introduction on the measurement methodology, error analysis and relevant statistics. The result can be used to indicate the performance of specific application and the congestion state on the path traversed. For a given Type-P, the Src host continually generates the test packet stream according to the given methodology and place a time stamp in the Type-P packet before sending it towards Dst, the Dst host takes a time stamp if the packet arrives within a reasonable period of time and computes the one-way- delay. As a specific implementation, the One-Way Active Measurement Protocol (OWAMP) [RFC4656] is designed to measure unidirectional characteristics including one-way delay and one-way loss. OWAMP actually consists of two inter-related protocols: OWAMP-Control and OWAMP-Test. OWAMP-Control is used to initiate, start, and stop test sessions and to fetch their results, whereas OWAMP-Test is used to exchange test packets between two measurement nodes. OWAMP-Control is designed to support the negotiation of one-way active measurement sessions and results retrieval. At session initiation, there is a negotiation of sender and receiver addresses and port numbers, session start time, session length, test packet size, the mean Poisson sampling interval for the test stream, and some attributes of the very general [RFC2330] notion of packet type, including packet size and per-hop behavior (PHB) [RFC2474], which could be used to support the measurement of one-way network characteristics across differentiated services networks. As the difference between the one-way-delay [RFC2679] of the selected pair of packets, IP Packet Delay Variation Metric for IP Performance Metrics [RFC3393] is defined with detailed introduction on the measurement methodology, error analysis and relevant statistics. The result can be used to size play-out buffers for applications requiring the regular delivery of packets, or to determine the dynamics of queues within a network. For a given Type-P, a selection function is defined to select pair of packets from the stream [Page 3] Internet-Draft DLN Gap Analysis October 2016 generated by the Src host within a specific interval (I1,I2). After the one-way-delay measurement is completed, the ipdv value of the pair of packets is obtained by subtracting the first value of one- way-delay form the second value. The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is based on OWAMP but adds capabilities of two-way or round-trip measurement. The TWAMP-Test protocol is similar to the OWAMP-test protocol [RFC4656] with the exception that the Session-Reflector transmits test packets to the Session-Sender in response to each test packet it receives. TWAMP defines two different test packet formats, one for packets transmitted by the Session-Sender and one for packets transmitted by the Session-Reflector. Further, the Session-Reflector does not need to know the Session-Sender behavior to the degree of detail as needed in OWAMP [RFC4656]. Additionally, the Session-Sender collects and records the necessary information provided from the packets transmitted by the Session-Reflector for measuring two-way metrics. The information recording based on the packet(s) received by the Session-Sender is implementation dependent. 2.2. Work in the MPLS WG The MPLS Work Group has also published some standard track RFCs which specify the performance monitoring mechanisms in the MPLS data plane. [RFC6374] "Packet Loss and Delay Measurement for MPLS Networks" specifies two closely related protocols, one for packet loss measurement (LM) and one for packet delay measurement (DM). The LM and DM protocols operate over the MPLS Generic Associated Channel (G- ACh) [RFC5586] and support measurement of loss, delay, and related metrics over Label Switched Paths (LSPs), pseudowires, and MPLS sections (links). The LM and DM protocols can be used both for continuous/proactive and selective/on-demand measurement. They can be implemented in hardware and support the higher precision IEEE 1588 timestamps. In an MPLS network, MPLS OAM tools can be used to measure latency, delay variation, and loss as described in [RFC6374]. It should be noted that queuing delays is not included in the delay measurement. Actually, for links, such as Forwarding Adjacencies, several methods are proposed in [RFC7823] for measuring the associated delay while avoiding significant queuing delay. [Page 4] Internet-Draft DLN Gap Analysis October 2016 2.3. Work in the Control Protocols Delay as a traffic engineering parameter has also been considered in intra-domain routing protocols (e.g., IS-IS [RFC7810] and OSPF [RFC7471]), and other control plane protocols including [RFC7823]. - Extension to OSPF [RFC7471] describes the extensions to OSPFv2 and OSPFv3 TE metric to support the distribution of network performance information, including unidirectional link delay, delay variation and etc. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. But the document does not specify any mechanisms for measuring network performance information, nor provides any algorithms for using the network-wide distributed information. - Extension to IS-IS Similarly, [RFC7810] describes the extensions to IS-IS TE metric to support the distribution of network performance information, including unidirectional link delay, delay variation and etc. The information distributed using IS-IS TE Metric Extensions can then be used to make path selection decisions based on network performance. But the document does not specify any mechanisms for measuring network performance information, nor provides any algorithms for using the network-wide distributed information. - Explicit Routed LSP path selection based on performance [RFC7823] describes network performance criteria in selecting the path for an explicitly routed RSVP-TE Label Switched Path (LSP). It also describes how a path computation function may use network performance data to perform such path selections. Note that the mechanisms described in the above documents only disseminate performance information but queuing delays are not considered. 3. Discussions The existing measuring methodologies focus on peer to peer or end to end measurement of delay, the measurement result may consist of transmission delay, propagation delay and storing delay which may change dramatically when there is congestion in the path across a network. Little work has been done on the delay measurement of scheduling on a single node, which may be critical in analyzing the forwarding delay on a node and further improving its latency performance. As describe above, both OWAMP and TWAMP use special test [Page 5] Internet-Draft DLN Gap Analysis October 2016 and control protocol to get the end to end delay of measurement packets along the Internet path under test. The result may be not enough to represent the delay of specific delay-sensitive traffic as the test packet may experience different congestion from the service packet. Meanwhile, test traffic may also aggravate network traffic congestion and cause higher latency in the network. The control plane protocols as described above are not sufficient to support routing and traffic engineering of the low latency service traffic. 4. Security Considerations This document analyzes the standardization work on synchronization in different SDOs. As no solution is proposed in this document, no security concerns are raised. 5. IANA Considerations There are no IANA actions required by this document. 6. References 6.1. Informative References [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998, [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC4656] S. Shalunov, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, September 2006. [Page 6] Internet-Draft DLN Gap Analysis October 2016 [RFC5357] K. Hedayat, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, October, 2008. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011. 7. Acknowledgments TBD Authors' Addresses Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: jiangyuanlong@huawei.com Xian Liu Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: lene.liuxian@huawei.com [Page 7]