Internet DRAFT - draft-jiang-dln-gap-analysis
draft-jiang-dln-gap-analysis
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]
