[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

DetNet                                                          D. Huang
Internet-Draft                                                       ZTE
Intended status: Standards Track                       December 13, 2017
Expires: June 16, 2018


                            Single-path PREF
                 draft-huang-detnet-single-path-pref-00

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 June 16, 2018.

Copyright Notice

   Copyright (c) 2017 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 June 16, 2018                 [Page 1]


Internet-Draft              Single-path PREF               December 2017


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 June 16, 2018                 [Page 2]


Internet-Draft              Single-path PREF               December 2017


   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 June 16, 2018                 [Page 3]


Internet-Draft              Single-path PREF               December 2017


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       |  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 PW 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 work 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 June 16, 2018                 [Page 4]


Internet-Draft              Single-path PREF               December 2017


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 June 16, 2018                 [Page 5]


Internet-Draft              Single-path PREF               December 2017


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 June 16, 2018                 [Page 6]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/