Internet DRAFT - draft-huang-detnet-single-path-pref
draft-huang-detnet-single-path-pref
DetNet D. Huang
Internet-Draft ZTE
Intended status: Standards Track June 12, 2018
Expires: December 14, 2018
Single-path PREF
draft-huang-detnet-single-path-pref-01
Abstract
This document specifies PREF on the single path for low-rate traffic,
and illustrates in details the implementation solutions as well as
the impacts on the data plane specified in [I-D.ietf-detnet-dp-alt].
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 https://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 December 14, 2018.
Copyright Notice
Copyright (c) 2018 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
(https://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.
Huang Expires December 14, 2018 [Page 1]
Internet-Draft Single-path PREF June 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Convention used in this document . . . . . . . . . . . . . . 3
3. Terminology and definitions . . . . . . . . . . . . . . . . . 3
4. Encapsulation impacts . . . . . . . . . . . . . . . . . . . . 3
4.1. Flow ID/Label . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Control word . . . . . . . . . . . . . . . . . . . . . . 4
5. Replication solutions . . . . . . . . . . . . . . . . . . . . 4
5.1. Discontinuous traffic . . . . . . . . . . . . . . . . . . 5
5.2. Continuous traffic . . . . . . . . . . . . . . . . . . . 5
6. Forwarder clarifications . . . . . . . . . . . . . . . . . . 5
6.1. Edge node clarifications . . . . . . . . . . . . . . . . 5
6.2. Relay node clarification . . . . . . . . . . . . . . . . 5
7. Traffic rate limit . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
PREF is designed to protect the Detnet traffic against path or node
failures in [I-D.ietf-detnet-architecture] by directing multiple
copies of the traffic into multiple paths. Lost packets would be
recovered at the converging node (or terminating node) from the
undamaged traffic in other path. Nevertheless, path and node failure
always result in disastrous consequences for the ongoing service,
large blocks of data loss or even total service breakdown, while PREF
with multiple paths protection would also provide good cross-check
for the minor packet loss which guarantees the data integrity as well
as latency benefits (retransmission reduced significantly). When it
comes to the latter scenario, PREF on the single path will do the
better job particularly for the low-rate traffic.
Packet replication is executed in edge node, what's significantly
different from the multi-path PREF is the copies would be arranged in
the same traffic flow rather than delivering along different paths,
either transport or forwarding nodes do not have to execute PREF
which should only be done at the terminating node. The rationale is
that if packet loss occurs at any intermediary nodes, the multiple
packet copies could execute cross-checking and rebuild the damaged
data flow, and make the usual retransmission unnecessary to a large
degree. Two major benefits follow, intermediary network nodes do not
need support PREF, and if the node is a PREF node, it does not
execute PREF. Secondly, no or reduced buffer reservation should be
required in the nodes along the routing path.
Multiple copies in the same data traffic put bandwidth pressure upon
the network without appropriate constraints. Low-rate traffic
Huang Expires December 14, 2018 [Page 2]
Internet-Draft Single-path PREF June 2018
services such as blockchain, IoT etc. from the use cases in
[I-D.ietf-detnet-use-cases] are proper for PREF on the single path to
provide service protection as well as latency reduction.
2. Convention 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].
The lowercase forms with an initial capital "Must", "Must
Not","Shall", "Shall Not", "Should", "Should Not", "May", and
"Optional"in this document are to be interpreted in the sense defined
in [RFC2119], but are used where the normative behavior is defined in
documents published by SDOs other than the IETF.
3. Terminology and definitions
This document uses the terms defined in
[I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-dp-alt].
4. Encapsulation impacts
From detnet processing point of view, PREF in the single path for
low-rate traffic is not intrinsically different from PREF in multiple
paths as it is defined in [I-D.ietf-detnet-dp-alt]. Both flow ID and
control word are needed to identify the specific detnet flow as well
as packets. Therefore this document will try to reuse the
encapsulation mechanism in [I-D.ietf-detnet-dp-alt] with minor
optional modification to make PREF in the single path run as
designed.
4.1. Flow ID/Label
Under the mechanism of PREF in multiple paths, flow label also works
as an indicator to the DA-*-PE that PREF be executed other than
identifying the specific detnet flow. Nonetheless, PREF in the
single path involves simply the initiating and terminating side of
the detnet service, while the intermediary nodes execute neither
replication nor elimination. One bit indicator in the flow ID to
announce whether or not the ongoing detnet traffic has multiple
copies in the same stream is necessary. As Figure 1 shows, the bit
'R' represents the indicator for which the default value should be
'0' indicating no more than 1 copy of the packets in the current
stream, while '1' setting indicates that the current stream has more
than one copies of the packets.
Huang Expires December 14, 2018 [Page 3]
Internet-Draft Single-path PREF June 2018
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Reserved |R|D| 24 bit Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: DetNet Flow ID word
The latest data plane working group draft removes the original flow
ID definition, and instead leverages service label in MPLS PW and
flow label in IPv6 respectively. Maybe further extensions as
designed above in detnet label definitions in PW and IPv6 are
necessary. Detailed solutions would be provided upon expert
feedback.
4.2. Control word
Definitions of control word in both MPLS PW and IPv6 will be reused
for PREF in the single path, and revisions should be made according
to the latest development of the [I-D.ietf-detnet-dp-alt].
However, control word would be another opportunity to make the PREF-
in-the-single-path indication as an alternative solution against the
Flow label solution. The intrinsic mechanism would be pretty much
the same as in Flow label. One reserved bit is used to announce
whether or not the ongoing detnet traffic has multiple copies in the
same stream. '0' should be the default value indicating 'no PREF in
the single path', while '1' indicates yes as is shown in the Figure 2
and Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|0 0 0 0 Reserved |R| 16 bit sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: DetNet PW control word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| 16 bit sequence number | Reserved |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: DetNet IPv6 Destination Option
5. Replication solutions
Low-rate traffic consists of both continuous (constant rate or
invariable rate) and discontinuous traffic, so roughly there are two
solutions to make the replication of the traffic.
Huang Expires December 14, 2018 [Page 4]
Internet-Draft Single-path PREF June 2018
5.1. Discontinuous traffic
The burst data should be taken as one unit upon which the replication
is executed. The whole burst data block would be replicated in the
pre-routed traffic.
5.2. Continuous traffic
Whether or not the traffic is constant, continuous traffic first has
to be truncated evenly into units upon which the replication is
executed. The truncation criteria could both be unit size (100Kbytes
etc) and unit time (1 second etc.).
6. Forwarder clarifications
PREF in the single path proposed in this document is a sub-part of
the PREF in the multiple paths defined in [I-D.ietf-detnet-dp-alt].
Upon receiving the DetNet flow packet, 'R' bit which is set to be '1'
should initiate PREF-in-the-single-path processing in the relay or
edge nodes.
The output of the single-path PREF elimination function is always a
single packet, and the output of the single-path replication is
always one or more packets. The replicated packets MUST share the
same DetNet control word sequence number.
6.1. Edge node clarifications
Also as specified in the multiple-paths PREF data plane document,
edge node extended forwarder is responsible to push DetNet header
(flow label and control word etc.) into the packets (if not already
present) before forwarding to other nodes.
The terminating edge node should execute the singple-path PREF
elimination which receives a specific packet while ignoring the other
copies with the same control word sequence numbers.
6.2. Relay node clarification
Upon receiving the DetNet flow packets, relay node check if it's
single-path PREF replications, namely whether or not 'R' is set to be
'1'. if it is single-path PREF replications, the relay node simply
forwards the packet as usual and executes no more processing. If the
boolean multiple-path PREF switch is on, the corresponding PREF
processing is executed normally.
Huang Expires December 14, 2018 [Page 5]
Internet-Draft Single-path PREF June 2018
7. Traffic rate limit
The single-path PREF is designed to address the low-rate traffic.
The traffic rate limit should be subject to the service providers.
The rate limit could be configured in both application level and
network management level.
8. Normative References
[I-D.ietf-detnet-architecture]
Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", draft-ietf-
detnet-architecture-03 (work in progress), August 2017.
[I-D.ietf-detnet-dp-alt]
Korhonen, J., Farkas, J., Mirsky, G., Thubert, P.,
Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol
and Solution Alternatives", draft-ietf-detnet-dp-alt-00
(work in progress), October 2016.
[I-D.ietf-detnet-use-cases]
Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y.,
Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,
X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D.,
Geng, X., Dujovne, D., and M. Seewald, "Deterministic
Networking Use Cases", draft-ietf-detnet-use-cases-13
(work in progress), September 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters",
RFC 6003, DOI 10.17487/RFC6003, October 2010,
<https://www.rfc-editor.org/info/rfc6003>.
Author's Address
Daniel Huang
ZTE corporation, Inc.
No.50 Software Avenue
Nanjing, Jiangsu 210012
P.R.China
Email: huang.guangping@zte.com.cn
URI: http://www.zte.com.cn
Huang Expires December 14, 2018 [Page 6]