idnits 2.17.1 draft-jiang-dln-gap-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2728 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 84, but not defined == Missing Reference: 'RFC2474' is mentioned on line 126, but not defined == Missing Reference: 'RFC5586' is mentioned on line 167, but not defined == Missing Reference: 'RFC7823' is mentioned on line 211, but not defined == Missing Reference: 'RFC7810' is mentioned on line 200, but not defined ** Obsolete undefined reference: RFC 7810 (Obsoleted by RFC 8570) == Missing Reference: 'RFC7471' is mentioned on line 189, but not defined == Unused Reference: 'RFC1305' is defined on line 253, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Y. Jiang 2 Internet-Draft X. Liu 3 Intended status: Informational Huawei 5 Expires: April 2017 October 31, 2016 7 Gap Analysis of Deterministic Latency Networks 8 draft-jiang-dln-gap-analysis-00 10 Abstract 12 Deterministic latency network (DLN) is needed to provide guaranteed 13 deterministic latency for use cases such as Cloud VR/Gaming and etc, 14 especially for latency-critical traffic. This document analyzes the 15 gaps in the existing IETF work on fulfilling the control plane and 16 measurement needs of DLN. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on April 31, 2013. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction .............................................. 2 58 1.1. Conventions used in this document ...................... 2 59 1.2. Terminology ............................................ 2 60 2. Related Standardization Work in the IETF .................. 3 61 2.1. Work in the IPPM WG .................................... 3 62 2.2. Work in the MPLS WG .................................... 4 63 2.3. Work in the Control Protocols .......................... 5 64 3. Discussions ............................................... 5 65 4. Security Considerations ................................... 6 66 5. IANA Considerations ....................................... 6 67 6. References ................................................ 6 68 6.1. Informative References ................................. 6 69 7. Acknowledgments ........................................... 7 71 1. Introduction 73 Deterministic latency network (DLN) is needed to provide guaranteed 74 deterministic latency for use cases such as Cloud VR/Gaming and etc, 75 especially for latency-critical traffic. This document analyzes the 76 gaps in the existing IETF work on fulfilling the control plane and 77 measurement needs of DLN. 79 1.1. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 1.2. Terminology 87 NTP Network Time Protocol 89 PHB per-hop behavior 91 2. Related Standardization Work in the IETF 93 2.1. Work in the IPPM WG 95 The IPPM Work Group has developed quite a lot of RFCs which specify 96 standard metrics including quality, performance and reliability that 97 can be used for the IP services. These protocols are usually 98 implemented as software modules, and they rely on IP and TCP protocol 99 stacks, as well as elements of the Network Time Protocol (NTP). 101 A One-way Delay Metric for IPPM [RFC2679] is defined for packets 102 across Internet paths based on notions introduced in the IPPM 103 framework [RFC2330] with detailed introduction on the measurement 104 methodology, error analysis and relevant statistics. The result can 105 be used to indicate the performance of specific application and the 106 congestion state on the path traversed. For a given Type-P, the Src 107 host continually generates the test packet stream according to the 108 given methodology and place a time stamp in the Type-P packet before 109 sending it towards Dst, the Dst host takes a time stamp if the packet 110 arrives within a reasonable period of time and computes the one-way- 111 delay. 113 As a specific implementation, the One-Way Active Measurement Protocol 114 (OWAMP) [RFC4656] is designed to measure unidirectional 115 characteristics including one-way delay and one-way loss. OWAMP 116 actually consists of two inter-related protocols: OWAMP-Control and 117 OWAMP-Test. OWAMP-Control is used to initiate, start, and stop test 118 sessions and to fetch their results, whereas OWAMP-Test is used to 119 exchange test packets between two measurement nodes. OWAMP-Control 120 is designed to support the negotiation of one-way active measurement 121 sessions and results retrieval. At session initiation, there is a 122 negotiation of sender and receiver addresses and port numbers, 123 session start time, session length, test packet size, the mean 124 Poisson sampling interval for the test stream, and some attributes of 125 the very general [RFC2330] notion of packet type, including packet 126 size and per-hop behavior (PHB) [RFC2474], which could be used to 127 support the measurement of one-way network characteristics across 128 differentiated services networks. 130 As the difference between the one-way-delay [RFC2679] of the selected 131 pair of packets, IP Packet Delay Variation Metric for IP Performance 132 Metrics [RFC3393] is defined with detailed introduction on the 133 measurement methodology, error analysis and relevant statistics. The 134 result can be used to size play-out buffers for applications 135 requiring the regular delivery of packets, or to determine the 136 dynamics of queues within a network. For a given Type-P, a selection 137 function is defined to select pair of packets from the stream 138 generated by the Src host within a specific interval (I1,I2). After 139 the one-way-delay measurement is completed, the ipdv value of the 140 pair of packets is obtained by subtracting the first value of one- 141 way-delay form the second value. 143 The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is based on 144 OWAMP but adds capabilities of two-way or round-trip measurement. The 145 TWAMP-Test protocol is similar to the OWAMP-test protocol [RFC4656] 146 with the exception that the Session-Reflector transmits test packets 147 to the Session-Sender in response to each test packet it receives. 148 TWAMP defines two different test packet formats, one for packets 149 transmitted by the Session-Sender and one for packets transmitted by 150 the Session-Reflector. Further, the Session-Reflector does not need 151 to know the Session-Sender behavior to the degree of detail as needed 152 in OWAMP [RFC4656]. Additionally, the Session-Sender collects and 153 records the necessary information provided from the packets 154 transmitted by the Session-Reflector for measuring two-way metrics. 155 The information recording based on the packet(s) received by the 156 Session-Sender is implementation dependent. 158 2.2. Work in the MPLS WG 160 The MPLS Work Group has also published some standard track RFCs which 161 specify the performance monitoring mechanisms in the MPLS data plane. 163 [RFC6374] "Packet Loss and Delay Measurement for MPLS Networks" 164 specifies two closely related protocols, one for packet loss 165 measurement (LM) and one for packet delay measurement (DM). The LM 166 and DM protocols operate over the MPLS Generic Associated Channel (G- 167 ACh) [RFC5586] and support measurement of loss, delay, and related 168 metrics over Label Switched Paths (LSPs), pseudowires, and MPLS 169 sections (links). The LM and DM protocols can be used both for 170 continuous/proactive and selective/on-demand measurement. They can be 171 implemented in hardware and support the higher precision IEEE 1588 172 timestamps. 174 In an MPLS network, MPLS OAM tools can be used to measure latency, 175 delay variation, and loss as described in [RFC6374]. It should be 176 noted that queuing delays is not included in the delay measurement. 177 Actually, for links, such as Forwarding Adjacencies, several methods 178 are proposed in [RFC7823] for measuring the associated delay while 179 avoiding significant queuing delay. 181 2.3. Work in the Control Protocols 183 Delay as a traffic engineering parameter has also been considered in 184 intra-domain routing protocols (e.g., IS-IS [RFC7810] and OSPF 185 [RFC7471]), and other control plane protocols including [RFC7823]. 187 - Extension to OSPF 189 [RFC7471] describes the extensions to OSPFv2 and OSPFv3 TE metric to 190 support the distribution of network performance information, 191 including unidirectional link delay, delay variation and etc. The 192 information distributed using OSPF TE Metric Extensions can then be 193 used to make path selection decisions based on network performance. 194 But the document does not specify any mechanisms for measuring 195 network performance information, nor provides any algorithms for 196 using the network-wide distributed information. 198 - Extension to IS-IS 200 Similarly, [RFC7810] describes the extensions to IS-IS TE metric to 201 support the distribution of network performance information, 202 including unidirectional link delay, delay variation and etc. The 203 information distributed using IS-IS TE Metric Extensions can then be 204 used to make path selection decisions based on network performance. 205 But the document does not specify any mechanisms for measuring 206 network performance information, nor provides any algorithms for 207 using the network-wide distributed information. 209 - Explicit Routed LSP path selection based on performance 211 [RFC7823] describes network performance criteria in selecting the 212 path for an explicitly routed RSVP-TE Label Switched Path (LSP). It 213 also describes how a path computation function may use network 214 performance data to perform such path selections. Note that the 215 mechanisms described in the above documents only disseminate 216 performance information but queuing delays are not considered. 218 3. Discussions 220 The existing measuring methodologies focus on peer to peer or end to 221 end measurement of delay, the measurement result may consist of 222 transmission delay, propagation delay and storing delay which may 223 change dramatically when there is congestion in the path across a 224 network. Little work has been done on the delay measurement of 225 scheduling on a single node, which may be critical in analyzing the 226 forwarding delay on a node and further improving its latency 227 performance. As describe above, both OWAMP and TWAMP use special test 228 and control protocol to get the end to end delay of measurement 229 packets along the Internet path under test. The result may be not 230 enough to represent the delay of specific delay-sensitive traffic as 231 the test packet may experience different congestion from the service 232 packet. Meanwhile, test traffic may also aggravate network traffic 233 congestion and cause higher latency in the network. 235 The control plane protocols as described above are not sufficient to 236 support routing and traffic engineering of the low latency service 237 traffic. 239 4. Security Considerations 241 This document analyzes the standardization work on synchronization in 242 different SDOs. As no solution is proposed in this document, no 243 security concerns are raised. 245 5. IANA Considerations 247 There are no IANA actions required by this document. 249 6. References 251 6.1. Informative References 253 [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, 254 Implementation and Analysis", RFC 1305, March 1992 256 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 257 "Framework for IP Performance Metrics", RFC 2330, May 1998, 259 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 260 Delay Metric for IPPM", RFC 2679, September 1999. 262 [RFC3393] C. Demichelis, "IP Packet Delay Variation Metric for IP 263 Performance Metrics (IPPM)", RFC 3393, November 2002. 265 [RFC4656] S. Shalunov, "A One-way Active Measurement Protocol 266 (OWAMP)", RFC 4656, September 2006. 268 [RFC5357] K. Hedayat, "A Two-Way Active Measurement Protocol (TWAMP)", 269 RFC 5357, October, 2008. 271 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement 272 for MPLS Networks", RFC 6374, September 2011. 274 7. Acknowledgments 276 TBD 278 Authors' Addresses 280 Yuanlong Jiang 281 Huawei Technologies Co., Ltd. 282 Bantian, Longgang district 283 Shenzhen 518129, China 284 Email: jiangyuanlong@huawei.com 286 Xian Liu 287 Huawei Technologies Co., Ltd. 288 Bantian, Longgang district 289 Shenzhen 518129, China 290 Email: lene.liuxian@huawei.com