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

Versions: 00

DetNet                                                     B. Varga, Ed.
Internet-Draft                                                 J. Farkas
Intended status: Standards Track                                Ericsson
Expires: November 6, 2019                                      L. Berger
                                                                D. Fedyk
                                                 LabN Consulting, L.L.C.
                                                                A. Malis
                                                               S. Bryant
                                                     Huawei Technologies
                                                             J. Korhonen
                                                             May 5, 2019


                         DetNet Data Plane: IP
                        draft-ietf-detnet-ip-00

Abstract

   This document specifies the Deterministic Networking data plane when
   operating in an IP packet switched network.

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 November 6, 2019.

Copyright Notice

   Copyright (c) 2019 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



Varga, et al.           Expires November 6, 2019                [Page 1]


Internet-Draft                  DetNet IP                       May 2019


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Terms Used In This Document . . . . . . . . . . . . . . .   3
     2.2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  DetNet IP Data Plane Overview . . . . . . . . . . . . . . . .   4
   4.  DetNet IP Data Plane Considerations . . . . . . . . . . . . .   6
     4.1.  End-System Specific Considerations  . . . . . . . . . . .   7
     4.2.  DetNet Domain-Specific Considerations . . . . . . . . . .   7
       4.2.1.  DetNet Routers  . . . . . . . . . . . . . . . . . . .   8
     4.3.  OAM . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Class of Service  . . . . . . . . . . . . . . . . . . . .  10
     4.5.  Quality of Service  . . . . . . . . . . . . . . . . . . .  10
     4.6.  Cross-DetNet Flow Resource Aggregation  . . . . . . . . .  10
     4.7.  Flow Identification and Aggregation . . . . . . . . . . .  11
     4.8.  Bidirectional Traffic . . . . . . . . . . . . . . . . . .  11
     4.9.  Aggregation Considerations  . . . . . . . . . . . . . . .  12
   5.  DetNet IP Data Plane Procedures . . . . . . . . . . . . . . .  12
     5.1.  DetNet IP Flow Identification Procedures  . . . . . . . .  13
       5.1.1.  IP Header Information . . . . . . . . . . . . . . . .  13
       5.1.2.  Other Protocol Header Information . . . . . . . . . .  14
     5.2.  Forwarding Procedures . . . . . . . . . . . . . . . . . .  15
     5.3.  DetNet IP Traffic Treatment Procedures  . . . . . . . . .  16
   6.  Flow Identification Management and Control Information  . . .  16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   9.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     11.1.  Normative references . . . . . . . . . . . . . . . . . .  19
     11.2.  Informative references . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   Deterministic Networking (DetNet) is a service that can be offered by
   a network to DetNet flows.  DetNet provides these flows extremely low
   packet loss rates and assured maximum end-to-end delivery latency.
   General background and concepts of DetNet can be found in the DetNet
   Architecture [I-D.ietf-detnet-architecture].




Varga, et al.           Expires November 6, 2019                [Page 2]


Internet-Draft                  DetNet IP                       May 2019


   This document specifies the DetNet data plane operation for IP hosts
   and routers that provide DetNet service to IP encapsulated data.  No
   DetNet specific encapsulation is defined to support IP flows, instead
   the existing IP and higher layer protocol header information is used
   to support flow identification and DetNet service delivery.  Common
   data plane procedures and control information for all DetNet data
   planes can be found in the [I-D.ietf-detnet-framework].

   The DetNet Architecture models the DetNet related data plane
   functions decomposed into two sub-layers: functions into two sub-
   layers: a service sub-layer and a forwarding sub-layer.  The service
   sub-layer is used to provide DetNet service protection and
   reordering.  The forwarding sub-layer is used to provides congestion
   protection (low loss, assured latency, and limited reordering).
   Since no DetNet specific headers are added to support DetNet IP
   flows, only the forwarding sub-layer functions are supported using
   the DetNet IP defined by this document.  Service protection can be
   provided on a per sub-net basis using technologies such as MPLS
   [I-D.ietf-detnet-dp-sol-mpls] and Ethernet as specified in the IEEE
   802.1 TSN task group(referred to in this document simply as IEEE802.1
   TSN).

   This document provides an overview of the DetNet IP data plane in
   Section 3, considerations that apply to providing DetNet services via
   the DetNet IP data plane in Section 4.  Section 5 provides the
   procedures for hosts and routers that support IP-based DetNet
   services.

2.  Terminology

2.1.  Terms Used In This Document

   This document uses the terminology and concepts established in the
   DetNet architecture [I-D.ietf-detnet-architecture], and the reader is
   assumed to be familiar with that document and its terminology.

2.2.  Abbreviations

   The following abbreviations used in this document:

   CoS           Class of Service.

   DetNet        Deterministic Networking.

   DN            DetNet.

   DiffServ      Differentiated Services




Varga, et al.           Expires November 6, 2019                [Page 3]


Internet-Draft                  DetNet IP                       May 2019


   DSCP          Differentiated Services Code Point

   L2            Layer-2.

   L3            Layer-3.

   LSP           Label-switched path.

   MPLS          Multiprotocol Label Switching.

   OAM           Operations, Administration, and Maintenance.

   PE            Provider Edge.

   PREOF         Packet Replication, Ordering and Elimination Function.

   PSN           Packet Switched Network.

   PW            Pseudowire.

   QoS           Quality of Service.

   TE            Traffic Engineering.

   TSN           Time-Sensitive Networking, TSN is a Task Group of the
                 IEEE 802.1 Working Group.

2.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  DetNet IP Data Plane Overview

   This document describes how IP is used by DetNet nodes, i.e., hosts
   and routers, identify DetNet flows and provide a DetNet service using
   an IP data plane.  From a data plane perspective, an end-to-end IP
   model is followed.  As mentioned above, existing IP and higher layer
   protocol header information is used to support flow identification
   and DetNet service delivery.  Common data plane procedures and
   control information for all DetNet data planes can be found in the
   [I-D.ietf-detnet-framework].

   The DetNet IP data plane uses "6-tuple" based flow identification,
   where 6-tuple refers to information carried in IP and higher layer



Varga, et al.           Expires November 6, 2019                [Page 4]


Internet-Draft                  DetNet IP                       May 2019


   protocol headers.  The 6-tuple referred to in this document is the
   same as that defined in [RFC3290].  Specifically 6-tuple is
   (destination address, source address, IP protocol, source port,
   destination port, and differentiated services (DiffServ) code point
   (DSCP).  General background on the use of IP headers, and 5-tuples,
   to identify flows and support Quality of Service (QoS) can be found
   in [RFC3670].  [RFC7657] also provides useful background on the
   delivery of DiffServ and "tuple" based flow identification.
   Referring to a 6-tuple allows DetNet nodes to forward packets with
   the 6-tuple as is or remap the DSCP where required by the DetNet
   service.

   DetNet flow aggregation may be enabled via the use of wildcards,
   masks, prefixes and ranges.  IP tunnels may also be used to support
   flow aggregation.  In these cases, it is expected that DetNet aware
   intermediate nodes will provide DetNet service assurance on the
   aggregate through resource allocation and congestion control
   mechanisms.

    DetNet IP       Relay                        Relay       DetNet IP
    End System      Node                         Node        End System

   +----------+                                             +----------+
   |   Appl.  |<------------ End to End Service ----------->|   Appl.  |
   +----------+  ............                 ...........   +----------+
   | Service  |<-: Service  :-- DetNet flow --: Service  :->| Service  |
   +----------+  +----------+                 +----------+  +----------+
   |Forwarding|  |Forwarding|                 |Forwarding|  |Forwarding|
   +--------.-+  +-.------.-+                 +-.---.----+  +-------.--+
            : Link :       \      ,-----.      /     \   ,-----.   /
            +......+        +----[  Sub  ]----+       +-[  Sub  ]-+
                                 [Network]              [Network]
                                  `-----'                `-----'

            |<--------------------- DetNet IP --------------------->|

             Figure 1: A Simple DetNet (DN) Enabled IP Network

   Figure 1 illustrates a DetNet enabled IP network.  The DetNet enabled
   end systems originate IP encapsulated traffic that is identified as
   DetNet flows, relay nodes understand the forwarding requirements of
   the DetNet flow and ensure that node, interface and sub-network
   resources are allocated to ensure DetNet service requirements.  The
   dotted line around the Service component of the Relay Nodes indicates
   that the transit routers are DetNet service aware but do not perform
   any DetNet service sub-layer function, e.g., PREOF.  IEEE 802.1 TSN
   is an example sub-network type which can provide support for DetNet
   flows and service.



Varga, et al.           Expires November 6, 2019                [Page 5]


Internet-Draft                  DetNet IP                       May 2019


   Note: The sub-network can represent a TSN, MPLS or IP network
   segment.

    IP              Edge                        Edge         IP
    End System      Node                        Node         End System

   +----------+   +.........+                 +.........+   +----------+
   |   Appl.  |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->|   Appl.  |
   +----------+   +.........+                 +.........+   +----------+
   |    IP    |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->|    IP    |
   +----------+   +---+ +---+                 +---+ +---+   +----------+
   |Forwarding|   |Fwd| |Fwd|                 |Fwd| |Fwd|   |Forwarding|
   +--------.-+   +-.-+ +-.-+                 +-.-+ +-.-+   +---.------+
            :  Link :      \      ,-----.      /     /  ,-----.  \
            +.......+       +----[  Sub  ]----+     +--[  Sub  ]--+
                                 [Network]             [Network]
                                  `-----'               `-----'

         |<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->|

      Figure 2: Non-DetNet aware IP end systems with DetNet IP Domain

   Figure 2 illustrates a variant of Figure 1 where the end systems are
   not DetNet aware.  In this case, edge nodes sit at the boundary of
   the DetNet domain and provide DetNet service proxies for the end
   applications by initiating and terminating DetNet service for the
   application's IP flows.  The existing header information or an
   approach such as described in Section 4.6 can be used to support
   DetNet flow identification.

   Non-DetNet and DetNet IP packets are identical on the wire.  From
   data plane perspective, the only difference is that there is flow-
   associated DetNet information on each DetNet node that defines the
   flow related characteristics and required forwarding behavior.  As
   shown above, edge nodes provide a Service Proxy function that
   "associates" one or more IP flows with the appropriate DetNet flow-
   specific information and ensures that the receives the proper traffic
   treatment within the domain.

   Note: The operation of IEEE802.1 TSN end systems over DetNet enabled
   IP networks is not described in this document.  TSN over MPLS is
   discribed in [I-D.ietf-detnet-tsn-over-mpls].

4.  DetNet IP Data Plane Considerations

   This section provides informative considerations related to providing
   DetNet service to flows which are identified based on their header
   information.



Varga, et al.           Expires November 6, 2019                [Page 6]


Internet-Draft                  DetNet IP                       May 2019


4.1.  End-System Specific Considerations

   Data-flows requiring DetNet service are generated and terminated on
   end systems.  This document deals only with IP end systems.  The
   protocols used by an IP end system are specific to an application and
   end systems peer with end systems using the same application
   encapsulation format.  This said, DetNet's use of 6-tuple IP flow
   identification means that DetNet must be aware of not only the format
   of the IP header, but also of the next protocol carried within an IP
   packet.

   When IP end systems are DetNet aware, no application-level or
   service-level proxy functions are needed inside the DetNet domain.
   For DetNet unaware IP end systems service-level proxy functions are
   needed inside the DetNet domain.

   End systems need to ensure that DetNet service requirements are met
   when processing packets associated with a DetNet flow.  When
   forwarding packets, this means that packets are appropriately shaped
   on transmission and received appropriate traffic treatment on the
   connected sub-network, see Section 4.5 and Section 4.2.1 for more
   details.  When receiving packets, this means that there are
   appropriate local node resources, e.g., buffers, to receive and
   process a DetNet flow packets.

4.2.  DetNet Domain-Specific Considerations

   As a general rule, DetNet IP domains need to be able to forward any
   DetNet flow identified by the IP 6-tuple.  Doing otherwise would
   limit end system encapsulation format.  From a practical standpoint
   this means that all nodes along the end-to-end path of DetNet flows
   need to agree on what fields are used for flow identification, and
   the transport protocols (e.g., TCP/UDP/IPsec) which can be used to
   identify 6-tuple protocol ports.

   From a connection type perspective two scenarios are identified:

   1.  DN attached: end system is directly connected to an edge node or
       end system is behind a sub-network.  (See ES1 and ES2 in figure
       below)

   2.  DN integrated: end system is part of the DetNet domain.  (See ES3
       in figure below)

   L3 (IP) end systems may use any of these connection types.  A DetNet
   domain allows communication between any end-systems using the same
   encapsulation format, independent of their connection type and DetNet
   capability.  DN attached end systems have no knowledge about the



Varga, et al.           Expires November 6, 2019                [Page 7]


Internet-Draft                  DetNet IP                       May 2019


   DetNet domain and its encapsulation format.  See Figure 3 for L3 end
   system connection examples.

                                               ____+----+
                       +----+        _____    /    | ES3|
                       | ES1|____   /     \__/     +----+___
                       +----+    \ /                        \
                                  +                          |
                          ____     \                        _/
            +----+     __/    \     +__  DetNet IP domain  /
            | ES2|____/  L2/L3 |___/   \         __     __/
            +----+    \_______/         \_______/  \___/



               Figure 3: Connection types of L3 end systems

4.2.1.  DetNet Routers

   Within a DetNet domain, the DetNet enabled IP Routers interconnect
   links and sub-networks to support end-to-end delivery of DetNet
   flows.  From a DetNet architecture perspective, these routers are
   DetNet relays, as they must be DetNet service aware.  Such routers
   identify DetNet flows based on the IP 6-tuple, and ensure that the
   DetNet service required traffic treatment is provided both on the
   node and on any attached sub-network.

   This solution provides DetNet functions end to end, but does so on a
   per link and sub-network basis.  Congestion protection and latency
   control and the resource allocation (queuing, policing, shaping) are
   supported using the underlying link / sub net specific mechanisms.
   However, service protections (packet replication and packet
   elimination functions) are not provided at the DetNet layer end to
   end.  Instead service protection can be provided on a per underlying
   L2 link and sub-network basis.

                     +------+                         +------+
                     |  X   |                         |  X   |
                     +======+                         +------+
          End-system |  IP  |                         |  IP  |
                -----+------+-------+======+---     --+======+--
          DetNet                    |L2/SbN|          |L2/SbN|
                                    +------+          +------+


   Figure 4: Encapsulation of DetNet Routing in simplified IP service L3
                                end-systems




Varga, et al.           Expires November 6, 2019                [Page 8]


Internet-Draft                  DetNet IP                       May 2019


   The DetNet Service Flow is mapped to the link / sub-network specific
   resources using an underlying system specific means.  This implies
   each DetNet aware node on path looks into the forwarded DetNet
   Service Flow packet and utilize e.g., a 5- (or 6-) tuple to find out
   the required mapping within a node.

   As noted earlier, the Service Protection is done within each link /
   sub-network independently using the domain specific mechanisms (due
   the lack of a unified end to end sequencing information that would be
   available for intermediate nodes).  Therefore, service protection (if
   enabled) cannot be provided end-to-end, only within sub-networks.
   This is shown for a three sub-network scenario in Figure 5, where
   each sub-network can provide service protection between its borders.


                                    ______
                          ____     /      \__
               ____      /     \__/          \___   ______
   +----+   __/    +====+                       +==+      \     +----+
   |src |__/ SubN1  )   |                       |  \ SubN3 \____| dst|
   +----+  \_______/    \       Sub-Network2    |   \______/    +----+
                         \_                    _/
                           \         __     __/
                            \_______/  \___/


             +---+        +---------E--------+      +-----+
   +----+    |   |        |         |        |      |     |      +----+
   |src |----R   E--------R     +---+        E------R     E------+ dst|
   +----+    |   |        |     |            |      |     |      +----+
             +---+        +-----R------------+      +-----+


    Figure 5: Replication and elimination in sub-networks for DetNet IP
                                 networks

   If end to end service protection is desired, it can be implemented,
   for example, by the DetNet end systems using Layer-4 (L4) transport
   protocols or application protocols.  However, these protocols are out
   of scope of this document.

4.3.  OAM

   [Editor's note: This section is TBD.  OAM may be dropped from this
   document and left for future study.]






Varga, et al.           Expires November 6, 2019                [Page 9]


Internet-Draft                  DetNet IP                       May 2019


4.4.  Class of Service

   Class of Service (CoS) for DetNet flows carried in IPv6 is provided
   using the standard differentiated services code point (DSCP) field
   [RFC2474] and related mechanisms.  The 2-bit explicit congestion
   notification (ECN) [RFC3168] field MAY also be used.

   One additional consideration for DetNet nodes which support CoS
   services is that they MUST ensure that the CoS service classes do not
   impact the congestion protection and latency control mechanisms used
   to provide DetNet QoS.  This requirement is similar to requirement
   for MPLS LSRs to that CoS LSPs do not impact the resources allocated
   to TE LSPs via [RFC3473].

4.5.  Quality of Service

   Quality of Service (QoS) for DetNet service flows carried in IP MUST
   be provided locally by the DetNet-aware hosts and routers supporting
   DetNet flows.  Such support leverages the underlying network layer
   such as 802.1 TSN.  The traffic control mechanisms used to deliver
   QoS for IP encapsulated DetNet flows are expected to be defined in a
   future document.  From an encapsulation perspective, the combination
   of the 6-tuple i.e., the typical 5-tuple enhanced with the DSCP code,
   uniquely identifies a DetNet service flow.

   Packets that are marked with a DetNet Class of Service value, but
   that have not been the subject of a completed reservation, can
   disrupt the QoS offered to properly reserved DetNet flows by using
   resources allocated to the reserved flows.  Therefore, the network
   nodes of a DetNet network must:

   o  Defend the DetNet QoS by discarding or remarking (to a non-DetNet
      CoS) packets received that are not the subject of a completed
      reservation.

   o  Not use a DetNet reserved resource, e.g. a queue or shaper
      reserved for DetNet flows, for any packet that does not carry a
      DetNet Class of Service marker.

4.6.  Cross-DetNet Flow Resource Aggregation

   The ability to aggregate individual flows, and their associated
   resource control, into a larger aggregate is an important technique
   for improving scaling of messaging in the data, management and
   control planes.  This document identifies the traffic identification
   related aspects of aggregation of DetNet flows.  The resource control
   and management aspects of aggregation (including the queuing/shaping/
   policing implications) will be covered in other documents.  The data



Varga, et al.           Expires November 6, 2019               [Page 10]


Internet-Draft                  DetNet IP                       May 2019


   plane implications of aggregation are independent for PW/MPLS and IP
   encapsulated DetNet flows.

   DetNet flows forwarded via IP have more limited aggregation options,
   due to the available traffic flow identification fields of the IP
   solution.  One available approach is to manage the resources
   associated with a DSCP identified traffic class and to map (remark)
   individually controlled DetNet flows onto that traffic class.  This
   approach also requires that nodes support aggregation ensure that
   traffic from aggregated LSPs are placed (shaped/policed/enqueued) in
   a fashion that ensures the required DetNet service is preserved.

   In both the MPLS and IP cases, additional details of the traffic
   control capabilities needed at a DetNet-aware node may be covered in
   the new service descriptions mentioned above or in separate future
   documents.  Management and control plane mechanisms will also need to
   ensure that the service required on the aggregate flow (H-LSP or
   DSCP) are provided, which may include the discarding or remarking
   mentioned in the previous sections.

4.7.  Flow Identification and Aggregation

   Section 3 introduces the use of the IP "6-tuple" for flow
   identification, and Section 4.5 goes on to discuss how identified
   flows use specific QoS mechanisms for flow-specific traffic
   treatment, including path control and resource allocation.
   Section 5.1 contains detailed DetNet IP flow identification
   procedures.  Flow identification plays an important role for the
   DetNet controller plane.

   Section 4.6 and Section 4.9 discuss the use of flow aggregation in
   DetNet.  Flow aggregation can be accomplished using any of the
   6-tuple fields defined in Section 5.1, using a DSCP identified
   traffic class or other field.  It will be the responsibility of the
   DetNet controller plane to be able to properly provision the use of
   these aggregation mechanisms.

4.8.  Bidirectional Traffic

   While the DetNet IP data plane must support bidirectional DetNet
   flows, there are no special bidirectional features with respect to
   the data plane other than the need for the two directions of a co-
   routed bidirectional flow to take the same path.  That is to say that
   bidirectional DetNet flows are solely represented at the management
   and control plane levels, without specific support or knowledge
   within the DetNet data plane.  Fate sharing and associated or co-
   routed bidirectional flows can be managed at the control level.




Varga, et al.           Expires November 6, 2019               [Page 11]


Internet-Draft                  DetNet IP                       May 2019


   Control and management mechanisms need to support bidirectional
   flows, but the specification of such mechanisms are out of scope of
   this document.  An example control plane solution for MPLS can be
   found in [RFC7551].

4.9.  Aggregation Considerations

   The use of prefixes, wildcards, bitmasks, and port ranges allows a
   DetNet node to aggregate DetNet flows.  This aggregation can take
   place within a single node, when that node maintains state about both
   the aggregated and component flows.  It can also take place between
   nodes, where one node maintains state about only flow aggregates
   while the other node maintains state on all or a portion of the
   component flows.  In either case, the management or control function
   that provisions the aggregate flows must ensure that adequate
   resources are allocated and configured to provide combined service
   requirements of the component flows.  As DetNet is concerned about
   latency and jitter, more than just bandwidth needs to be considered.

5.  DetNet IP Data Plane Procedures

   This section provides DetNet IP data plane procedures.  These
   procedures have been divided into the following areas: flow
   identification, forwarding and traffic treatment.  Flow
   identification includes those procedures related to matching IP and
   higher layer protocol header information to DetNet flow (state)
   information and service requirements.  Flow identification is also
   sometimes called Traffic classification, for example see [RFC5777].
   Forwarding includes those procedures related to next hop selection
   and delivery.  Traffic treatment includes those procedures related to
   providing an identified flow with the required DetNet service.

   DetNet IP data plane establishment and operational procedures also
   have requirements on the control and management systems for DetNet
   flows and these are covered in this section.  Specifically this
   section identifies a number of information elements that require
   support via the management and control interfaces supported by a
   DetNet node.  The specific mechanism used for such support is out of
   the scope of this document.  A summary of the requirements for
   management and control related information is included.  Conformance
   language is not used in the summary since applies to future
   mechanisms such as those that may be provided in YANG models [YANG-
   REF-TBD].








Varga, et al.           Expires November 6, 2019               [Page 12]


Internet-Draft                  DetNet IP                       May 2019


5.1.  DetNet IP Flow Identification Procedures

   IP and higher layer protocol header information is used to identify
   DetNet flows.  All DetNet implementations that support this document
   MUST identify individual DetNet flows based on the set of information
   identified in this section.  Note, that additional flow
   identification requirements, e.g., to support other higher layer
   protocols, may be defined in future.

   The configuration and control information used to identify an
   individual DetNet flow MUST be ordered by an implementation.
   Implementations MUST support a fixed order when identifying flows,
   and MUST identify a DetNet flow by the first set of matching flow
   information.

   Implementations of this document MUST support DetNet flow
   identification when the implementation is acting as a DetNet end
   systems, a relay node or as an edge node.

5.1.1.  IP Header Information

   Implementations of this document MUST support DetNet flow
   identification based on IP header information.  The IPv4 header is
   defined in [RFC0791] and the IPv6 is defined in [RFC8200].

5.1.1.1.  Source Address Field

   Implementations of this document MUST support DetNet flow
   identification based on the Source Address field of an IP packet.
   Implementations SHOULD support longest prefix matching for this
   field, see [RFC1812] and [RFC7608].  Note that a prefix length of
   zero (0) effectively means that the field is ignored.

5.1.1.2.  Destination Address Field

   Implementations of this document MUST support DetNet flow
   identification based on the Destination Address field of an IP
   packet.  Implementations SHOULD support longest prefix matching for
   this field, see [RFC1812] and [RFC7608].  Note that a prefix length
   of zero (0) effectively means that the field is ignored.

   Note: any IP address value is allowed, including an IP multicast
   destination address.








Varga, et al.           Expires November 6, 2019               [Page 13]


Internet-Draft                  DetNet IP                       May 2019


5.1.1.3.  IPv4 Protocol and IPv6 Next Header Fields

   Implementations of this document MUST support DetNet flow
   identification based on the IPv4 Protocol field when processing IPv4
   packets, and the IPv6 Next Header Field when processing IPv6 packets.
   An implementation MUST support flow identification based based the
   next protocol values defined in Section 5.1.2.  Other, non-zero
   values, MUST be used for flow identification.  Implementations SHOULD
   allow for these fields to be ignored for a specific DetNet flow.

5.1.1.4.  IPv4 Type of Service and IPv6 Traffic Class Fields

   These fields are used to support Differentiated Services [RFC2474]
   and Explicit Congestion Notification [RFC3168].  Implementations of
   this document MUST support DetNet flow identification based on the
   IPv4 Type of Service field when processing IPv4 packets, and the IPv6
   Traffic Class Field when processing IPv6 packets.  Implementations
   MUST support bitmask based matching, where bits set to one (1) in the
   bitmask indicate which subset of the bits in the field are to be used
   in determining a match.  Note that all bits set to zero (0) value as
   a bitmask effectively means that these fields are ignored.

5.1.1.5.  IPv6 Flow Label Field

   Implementations of this document SHOULD support identification of
   DetNet flows based on the IPv6 Flow Label field.  Implementations
   that support matching based on this field MUST allow for this field
   to be ignored for a specific DetNet flow.  When this field is used to
   identify a specific DetNet flow, implementations MAY exclude the IPv6
   Next Header field and next header information as part of DetNet flow
   identification.

5.1.2.  Other Protocol Header Information

   Implementations of this document MUST support DetNet flow
   identification based on header information identified in this
   section.  Support for TCP, UDP and IPsec flows is defined.  Future
   documents are expected to define support for other protocols.

5.1.2.1.  TCP and UDP

   DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is
   achieved based on the Source and Destination Port fields carried in
   each protocol's header.  These fields share a common format and
   common DetNet flow identification procedures.






Varga, et al.           Expires November 6, 2019               [Page 14]


Internet-Draft                  DetNet IP                       May 2019


5.1.2.1.1.  Source Port Field

   Implementations of this document MUST support DetNet flow
   identification based on the Source Port field of a TCP or UDP packet.
   Implementations MUST support flow identification based on a
   particular value carried in the field, i.e., an exact value.
   Implementations SHOULD support range-based port matching.
   Implementation MUST also allow for the field to be ignored for a
   specific DetNet flow.

5.1.2.1.2.  Destination Port Field

   Implementations of this document MUST support DetNet flow
   identification based on the Destination Port field of a TCP or UDP
   packet.  Implementations MUST support flow identification based on a
   particular value carried in the field, i.e., an exact value.
   Implementations SHOULD support range-based port matching.
   Implementation MUST also allow for the field to be ignored for a
   specific DetNet flow.

5.1.2.2.  IPsec AH and ESP

   IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security
   Payload (ESP) [RFC4303] share a common format for the Security
   Parameters Index (SPI) field.  Implementations MUST support flow
   identification based on a particular value carried in the field,
   i.e., an exact value.  Implementation SHOULD also allow for the field
   to be ignored for a specific DetNet flow.

5.2.  Forwarding Procedures

   General requirements for IP nodes are defined in [RFC1122], [RFC1812]
   and [RFC6434], and are not modified by this document.  The typical
   next-hop selection process is impacted by DetNet.  Specifically,
   implementations of this document SHALL use management and control
   information to select the one or more outgoing interfaces and next
   hops to be used for a packet belonging to a DetNet flow.

   The use of multiple paths or links, e.g., ECMP, to support a single
   DetNet flow is NOT RECOMMENDED.  ECMP MAY be used for non-DetNet
   flows within a DetNet domain.

   The above implies that management and control functions will be
   defined to support this requirement, e.g., see [YANG-REF-TBD].







Varga, et al.           Expires November 6, 2019               [Page 15]


Internet-Draft                  DetNet IP                       May 2019


5.3.  DetNet IP Traffic Treatment Procedures

   Implementations if this document MUST ensure that a DetNet flow
   receives the traffic treatment that is provisioned for it via
   configuration or the controller plane, e.g., via [YANG-REF-TBD].
   General information on DetNet service can be found in
   [I-D.ietf-detnet-flow-information-model].  Typical mechanisms used to
   provide different treatment to different flows includes the
   allocation of system resources (such as queues and buffers) and
   provisioning or related parameters (such as shaping, and policing).
   Support can also be provided via an underlying network technology
   such as MPLS [I-D.ietf-detnet-ip-over-mpls].  and IEEE802.1 TSN
   [I-D.ietf-ip-over-tsn].  Other than in the TSN case, the specific
   mechanisms used by a DetNet node to ensure DetNet service delivery
   requirements are met for supported DetNet flows is outside the scope
   of this document.

6.  Flow Identification Management and Control Information

   The following summarizes the set of information that is needed to
   identify an individual DetNet flow:

   o  IPv4 and IPv6 source address field.

   o  IPv4 and IPv6 source address prefix length, where a zero (0) value
      effectively means that the address field is ignored.

   o  IPv4 and IPv6 destination address field.

   o  IPv4 and IPv6 destination address prefix length, where a zero (0)
      effectively means that the address field is ignored.

   o  IPv4 protocol field.  A limited set of values is allowed, and the
      ability to ignore this field, e.g., via configuration of the value
      zero (0), is desirable.

   o  IPv6 next header field.  A limited set of values is allowed, and
      the ability to ignore this field, e.g., via configuration of the
      value zero (0), is desirable.

   o  IPv4 Type of Service and IPv6 Traffic Class Fields.

   o  IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a
      zero (0) effectively means that theses fields are ignored.

   o  IPv6 flow label field.  This field can be optionally used for
      matching.  When used, can be exclusive of matching against the
      next header field.



Varga, et al.           Expires November 6, 2019               [Page 16]


Internet-Draft                  DetNet IP                       May 2019


   o  TCP and UDP Source Port.  Exact and wildcard matching is required.
      Port ranges can optionally be used.

   o  TCP and UDP Destination Port.  Exact and wildcard matching is
      required.  Port ranges can optionally be used.

   This information MUST be provisioned per DetNet flow via
   configuration, e.g., via the controller or management plane.

   Information identifying a DetNet flow is ordered and implementations
   use the first match.  This can, for example, be used to provide a
   DetNet service for a specific UDP flow, with unique Source and
   Destination Port field values, while providing a different service
   for all other flows with that same UDP Destination Port value.

7.  Security Considerations

   The security considerations of DetNet in general are discussed in
   [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-security].  Other
   security considerations will be added in a future version of this
   draft.

8.  IANA Considerations

   TBD.

9.  Contributors

   RFC7322 limits the number of authors listed on the front page of a
   draft to a maximum of 5, far fewer than the 20 individuals below who
   made important contributions to this draft.  The editor wishes to
   thank and acknowledge each of the following authors for contributing
   text to this draft.  See also Section 10.


















Varga, et al.           Expires November 6, 2019               [Page 17]


Internet-Draft                  DetNet IP                       May 2019


      Loa Andersson
      Huawei
      Email: loa@pi.nu

      Yuanlong Jiang
      Huawei
      Email: jiangyuanlong@huawei.com

      Norman Finn
      Huawei
      3101 Rio Way
      Spring Valley, CA  91977
      USA
      Email: norman.finn@mail01.huawei.com

      Janos Farkas
      Ericsson
      Magyar Tudosok krt. 11
      Budapest  1117
      Hungary
      Email: janos.farkas@ericsson.com

      Carlos J. Bernardos
      Universidad Carlos III de Madrid
      Av. Universidad, 30
      Leganes, Madrid  28911
      Spain
      Email: cjbc@it.uc3m.es

      Tal Mizrahi
      Marvell
      6 Hamada st.
      Yokneam
      Israel
      Email: talmi@marvell.com

      Lou Berger
      LabN Consulting, L.L.C.
      Email: lberger@labn.net

      Andrew G. Malis
      Huawei Technologies
      Email: agmalis@gmail.com

      Don Fedyk
      LabN Consulting, L.L.C.
      Email: dfedyk@labn.net




Varga, et al.           Expires November 6, 2019               [Page 18]


Internet-Draft                  DetNet IP                       May 2019


10.  Acknowledgements

   The author(s) ACK and NACK.

   The following people were part of the DetNet Data Plane Solution
   Design Team:

      Jouni Korhonen

      Janos Farkas

      Norman Finn

      Balazs Varga

      Loa Andersson

      Tal Mizrahi

      David Mozes

      Yuanlong Jiang

      Andrew Malis

      Carlos J.  Bernardos

   The DetNet chairs serving during the DetNet Data Plane Solution
   Design Team:

      Lou Berger

      Pat Thaler

   Thanks for Stewart Bryant for his extensive review of the previous
   versions of the document.

11.  References

11.1.  Normative references

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.



Varga, et al.           Expires November 6, 2019               [Page 19]


Internet-Draft                  DetNet IP                       May 2019


   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
              RFC 1812, DOI 10.17487/RFC1812, June 1995,
              <https://www.rfc-editor.org/info/rfc1812>.

   [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>.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              DOI 10.17487/RFC3473, January 2003,
              <https://www.rfc-editor.org/info/rfc3473>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.

   [RFC7608]  Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
              Length Recommendation for Forwarding", BCP 198, RFC 7608,
              DOI 10.17487/RFC7608, July 2015,
              <https://www.rfc-editor.org/info/rfc7608>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.





Varga, et al.           Expires November 6, 2019               [Page 20]


Internet-Draft                  DetNet IP                       May 2019


   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

11.2.  Informative references

   [I-D.ietf-detnet-architecture]
              Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", draft-ietf-
              detnet-architecture-12 (work in progress), March 2019.

   [I-D.ietf-detnet-dp-sol-mpls]
              Korhonen, J. and B. Varga, "DetNet MPLS Data Plane
              Encapsulation", draft-ietf-detnet-dp-sol-mpls-02 (work in
              progress), March 2019.

   [I-D.ietf-detnet-flow-information-model]
              Farkas, J., Varga, B., Cummings, R., and Y. Jiang, "DetNet
              Flow Information Model", draft-ietf-detnet-flow-
              information-model-03 (work in progress), March 2019.

   [I-D.ietf-detnet-framework]
              Korhonen, J., Varga, B., "DetNet Data Plane Framework",
              2019.

   [I-D.ietf-detnet-ip-over-mpls]
              Korhonen, J., Varga, B., "DetNet IP over DetNet MPLS Data
              Plane", 2019.

   [I-D.ietf-detnet-security]
              Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell,
              J., Austad, H., Stanton, K., and N. Finn, "Deterministic
              Networking (DetNet) Security Considerations", draft-ietf-
              detnet-security-04 (work in progress), March 2019.

   [I-D.ietf-detnet-tsn-over-mpls]
              Varga, B., "DetNet Data Plane: IEEE 802.1 Time Sensitive
              Networking over MPLS", 2019.

   [I-D.ietf-ip-over-tsn]
              Korhonen, J., Varga, B., "DetNet Data Plane: IP over IEEE
              802.1 Time Sensitive Networking (TSN)", 2019.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/info/rfc1122>.



Varga, et al.           Expires November 6, 2019               [Page 21]


Internet-Draft                  DetNet IP                       May 2019


   [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
              Informal Management Model for Diffserv Routers", RFC 3290,
              DOI 10.17487/RFC3290, May 2002,
              <https://www.rfc-editor.org/info/rfc3290>.

   [RFC3670]  Moore, B., Durham, D., Strassner, J., Westerinen, A., and
              W. Weiss, "Information Model for Describing Network Device
              QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670,
              January 2004, <https://www.rfc-editor.org/info/rfc3670>.

   [RFC5777]  Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
              Ed., and A. Lior, "Traffic Classification and Quality of
              Service (QoS) Attributes for Diameter", RFC 5777,
              DOI 10.17487/RFC5777, February 2010,
              <https://www.rfc-editor.org/info/rfc5777>.

   [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", RFC 6434, DOI 10.17487/RFC6434, December
              2011, <https://www.rfc-editor.org/info/rfc6434>.

   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
              Extensions for Associated Bidirectional Label Switched
              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
              <https://www.rfc-editor.org/info/rfc7551>.

   [RFC7657]  Black, D., Ed. and P. Jones, "Differentiated Services
              (Diffserv) and Real-Time Communication", RFC 7657,
              DOI 10.17487/RFC7657, November 2015,
              <https://www.rfc-editor.org/info/rfc7657>.

Authors' Addresses

   Balazs Varga (editor)
   Ericsson
   Magyar Tudosok krt. 11.
   Budapest  1117
   Hungary

   Email: balazs.a.varga@ericsson.com


   Janos Farkas
   Ericsson
   Magyar Tudosok krt. 11.
   Budapest  1117
   Hungary

   Email: janos.farkas@ericsson.com



Varga, et al.           Expires November 6, 2019               [Page 22]


Internet-Draft                  DetNet IP                       May 2019


   Lou Berger
   LabN Consulting, L.L.C.

   Email: lberger@labn.net


   Don Fedyk
   LabN Consulting, L.L.C.

   Email: dfedyk@labn.net


   Andrew G. Malis
   Huawei Technologies

   Email: agmalis@gmail.com


   Stewart Bryant
   Huawei Technologies

   Email: stewart.bryant@gmail.com


   Jouni Korhonen

   Email: jouni.nospam@gmail.com
























Varga, et al.           Expires November 6, 2019               [Page 23]


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