Network Working Group                                            S. Shah
Internet-Draft                                                P. Thubert
Intended status: Informational                             Cisco Systems
Expires: September 4, 2014 March 7, 2015                                September 03, 2014

                      Deterministic Forwarding PHB
             draft-svshah-tsvwg-deterministic-forwarding-01
             draft-svshah-tsvwg-deterministic-forwarding-02

Abstract

   This document defines a Differentiated Services Per-Hop-Behavior
   (PHB) Group called Deterministic Forwarding (DF).  The document
   describes the purpose and semantics of this PHB.  It also describes
   creation and forwarding treatment of the service class.  The document
   also  Also
   describes how the code-point can be mapped into one of the aggregated
   Diffserv service classes [RFC5127].

Status of this 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 http://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 September 4, 2014. March 7, 2015.

Copyright Notice

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology .  3
     1.1.  Use-cases . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology  . . .
   3.  DF Per Hop Behavior . . . . . . . . . . . . . . . . . . . . .   3
   4.  Traffic Conditioning  .  5
   3.  DF code-point Behavior . . . . . . . . . . . . . . . . . . .   4
   5.  Diffserv behavior through non-DF DS domain  .  5
     3.1.  Potential implementation of DF scheduling . . . . . . . .  6
     3.2.  Conditioning   4
   6.  Potential implementation of DF traffic at Enqueue . . . . . . . . . . . scheduling .  8
   4.  Diffserv behavior through non-DF DS domains . . . . . . . . .  8
   5.   5
   7.  Updates to RFC4594 and RFC5127  . . . . . . . . . . . . . . . .  8
   6.   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  8
   7.   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  9
   8.   7
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  9
   9.   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.   7
     11.2.  Informative References . . . . . . . . . . . . . . . . . .  9   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 10   8

1.  Introduction

   IP Networks typically implement Diffserv

   There is a demand to provide differentiated deterministic forwarding behavior to different class certain type
   of traffic.  Networks that
   implement Diffserv relies on DSCP code-point traffic in the IP header machine to machine networks over IP.  With an
   introduction of a
   packet machine to select PHB as a specific forwarding treatment for that
   packet [RFC2474, RFC2475].  This document describes machine networks over IP, a particular PHB
   called Deterministic Forwarding (DF).  The proposed new code-point
   defines a service class for the purpose of forwarding treatment set of a
   packet at determined/fixed scheduled time providing no jitter service
   to IP
   applications are emerging.  Traffic types from such applications/
   networks are some-what different from the class of traditional traffic (updates RFC4594 with the addition types.
   Though most traffic types have characteristics similar to that of a new
   Service Class).

   DF PHB can be used
   traditional ones [LLN-DIFF], certain control signals for some of the network services that require the
   capability
   applications are extremely sensitive to ensure a predictable interaction between networked
   systems latency and guarantee a very strict time jitter and thus
   timely scheduled services.
   Applications of delivery.  End to end deterministic path for such networks
   traffic may be able to absorb a loss but are
   very sensitive to timely(deterministic) delivery.  Examples of such
   networks include Machine through one or more administered inter-connected
   machine to Machine (M2M) control and monitoring
   deployment with IP over varieties of Layer 2 machine networks.

   The definition of Expedited

   Deterministic Forwarding (EF) [RFC2598] (DF) PHB group is low
   latency and thus a means for each node in
   machine to machine networks, in an end to end path, to deliver
   required deterministic behavior.  DF class in each DS node is
   allocated with a scheduled transmission time.  DS node may be
   allocated one can envision scheduled time for the whole aggregate DF traffic, or
   may be allocated with different schedule time for each micro-flow or
   set of micro-flows in a DF class.  IP packets that wish to use
   deterministic service are assigned DF code-point, typically at the
   originator of EF code-point for such
   service.  However, even though EF defines low latency traffic.

   In a DS node, the level of forwarding determinism of an IP packet
   depends on scheduled time, at which packet then serviced independent
   of existence and low jitter, load of any other type of traffic.  For example when
   a DF packet arrives at the DS node, it does not guarantee deterministic/fixed is queued until its
   provisioned scheduled time service.
   Depending on co-existence of service.  At the trigger of that
   scheduled time, service to all other traffic in is pre-empted to service
   DF traffic.

   This document describes the network, EF
   traffic may have more or less variance on jitter and thus DF PHB group.  DF capability is not
   suitable a
   required function for the deterministic service. a DS-compliant node, but a DS-compliant node
   that implements DF PHB, as defined PHB group MUST conform to the specification in
   this
   document, thus is more suitable for deterministic time sensitive
   traffic. document.

   Typically for an application where end to end deterministic service
   is important, relevant traffic should can be provisioned serviced through DF PHB at
   every hop in that end to end the path.  However, in cases where intermediate hops (or
   DS domains) either do not support DF PHB or supports only aggregated
   service classes described in RFC5127, DF traffic in those DS domains
   MUST be mapped to Real Time Treatment class (EF PHB) defined in
   RFC5127.  Traffic in such scenario MUST be conditioned at the Edge
   before entering and after exiting such DS domains.  This is described
   further in later section.

1.1.  Use-cases

   With an introduction of machine to machine networks over IP, a new
   set of applications are emerging.  Traffic types from such
   applications/networks are some-what different from the traditional
   traffic types.  Though most traffic types have characteristics
   similar to that of traditional ones [LLN-DIFF], certain control
   signals for some of the applications are extremely sensitive to
   latency and jitter thus deterministic service.  Such control signals
   demand much stricter latency and jitter, at pretty much decisive time
   scheduled delivery, end to end.  Industrial automation, Smart cities
   and automobiles/planes/trains built around such networks are examples
   of such use-cases.

   Machine to machine networks may be implemented on varieties of Layer
   2 protocols. 802.15e [TiSCH] and 802.1 are examples of layer 2 that
   are enhancing their capabilities to allow time scheduled delivery of
   packets.

                    ---+------------------------
                       |   Converged Campus Network
                       |
                    +-----+
                    |     | Gateway
                    |     |
                    +-----+
                       |
                       |      Backbone
                 +--------------------+------------------+
                 |                    |                  |
              +-----+             +-----+             +-----+
              |     | LLN border  |     | LLN border  |     | LLN border
         o    |     | router      |     | router      |     | router
              +-----+             +-----+             +-----+
         o                  o                   o                 o
             o    o   o         o   o  o   o         o  o   o o
             o o   o  o   o  o  o o   o  o  o   o   o   o  o  o  o o
            o  o o  o o    o   o   o  o  o  o       o  o  o o o
            o   o  M o  o  o     o  o    o  o  o    o  o   o  o   o
              o   o o       o        o  o         o        o o
                      o           o          o             o     o

                LLN-1               LLN-2              LLN-3

   Taking use-case example from [TiSCH], as shown in the diagram,
   multiple LL Networks are connected to each other via Backbone through
   LLN Border routers.  Each LL Network consist of many nodes.  There is
   different types of traffic forwarded through each LL node and from
   one LL Network to another.  Most LLN traffic types have
   characteristics similar to that of traditional ones and thus can be
   supported through existing Diffserv classes except time sensitive
   control signals.  Without segregating such control signals to a
   specific Diffserv class would require Intserv support for LLN traffic
   in such networks.  All traffic would be subject to flow
   classification to differentiate time sensitive control signals which
   can be a big scale concern.  Supporting time sensitive control
   signals via newly proposed DF Diffserv class allows implementation of
   Diffserv in LLN Networks.

2.  Terminology

   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.

3.  DF code-point Per Hop Behavior

   The DF PHB is to implement time scheduled deterministic scheduled, deterministic in
   terms of a time, forwarding treatment.
   Provisioning of such  DF traffic MUST be serviced
   in a service has two parts,

       1) Provisioning of the fixed/relative manner to meet configurable scheduled time.  A DS node may pre-
   allocate dedicated resources available at configured scheduled time
   for scheduling optionally configurable maximum size of such data.  Every conforming
   packet, belonging to DF class, gets deterministic service
       2) Provisioning of the max size
   irrespective of traffic in other Diffserv class and current load on
   the data to be transmitted at
          each system.  A DS node MAY allow though its dedicated scheduled
   resources available to other Differentiated service classes when DF
   class does not have any packets to serve during its service time.

   Provisioned scheduled time may

   A DS node MAY be absolute configured with the same parameters for the entire
   DF traffic class or relative. different parameters for each micro-flow in a DF
   class.  For example, the later case, DF traffic MUST be serviced in a manner
   to meet scheduled service time for each individual micro-flow.  Per-
   flow DF class parameters may be provisioned dynamically thru a signaling
   protocol.  Use of any signaling protocol is agnostic to schedule packets (or bytes) the DF PHB
   and thus out of scope of this specification [An example of such
   signaling protocol referred in 6TisCH].  What signaling protocol
   requires to convey, at every
   fixed time.  Fixed minimum to each DS node in the end to end
   path, is request for DF service along with the flow classification
   and associated DF parameters, parameters like intended time can of a
   service and size of data to be transmitted during time of a day or any other absolute
   definition. service.
   In a multi hop forwarding of packet path, packet first is classified if it belongs to DF traffic, absolute time
   service provisioning PHB.
   Once classified for DF PHB, it gets deterministic treatment if
   provisioned for per-flow DF parameters or else gets aggregate DF
   treatment.

4.  Traffic Conditioning

   A DF supported DS Domain MAY condition traffic at each hop may require to be dependent on the
   clock synchronization (clock synchronization is ingress Edge of
   the domain.  Traffic conditioning MUST discard any incoming packet
   that does not in conform to the scope of
   this specification).  In relative time scheduling, configured DF service.  As per PHB
   definition, packets are required to be scheduled and delivered at every specific interval a
   precise absolute or it could be relative to any
   other specific event/trigger.  The definition of the time interval or
   any other event is relevant to interval.  Any packet that specific provisioned node only.

   The size of has
   missed the data to be transmitted, at each scheduled window of its service time
   service, may MUST be provisioned in the unit of bytes or time.  The data
   defined here is raw data transmitted over transmission media,
   including Layer 2 header and any other overhead.  Once discarded.  For example
   if a DF PHB queue is provisioned to serve a packet with less than x ms of
   jitter and enabled, forwarding treatment MUST service packets
   (bytes) from this class at the for an arrived packet, if next scheduled time for max allowable size.
   Scheduling a packet
   results in more than x ms of jitter then such packet MUST pre-empt any other service, including EF, during be
   discarded.  The packet MUST also be checked against the
   schedule time service for size of the DF class.  In order to avoid incurred
   latency to EF class
   data.  If size of traffic, it the packet is expected to carefully provision
   DF class to limit bigger than max size of the data a
   scheduled time service is provisioned to as minimal data
   transmission that would prevent larger than expected delays service then such packet MUST be
   discarded.  In addition to EF
   class DS node at the ingress Edge of traffic.

   Provisioning can the domain,
   other DS nodes in the path MAY implement Traffic Conditioning.

5.  Diffserv behavior through non-DF DS domain

   In deployments if two DF domains are connected through a domain that
   does not support DF PHB, traffic from such intermediate domain MUST
   be done via any forwarded with low latency.  DF traffic at the egress Edge of multiple possible methods.  It
   could be via command interface, or could the
   sender DF domain MUST be via external provisioning
   agents, or could mapped to EF PHB aggregate service, defined
   as Real Time Service aggregation in RFC5127.  Such traffic when
   entered in the receiving DF domain MUST be via some sort conditioned, as described
   in earlier section, at the ingress Edge of signaling that may dynamically
   pre-negotiate time window of transmission at each node in a network
   path.

3.1. receiving domain.

6.  Potential implementation of DF scheduling

   Following are examples of potential implementations.  They are not
   any form of guidelines or recommendations but simply a reference to
   potential implementations.

    There are at least two ways to implement scheduling for DF traffic
    class.

    1) One queue to buffer and schedule all DF traffic (from all flows),

    2) Multiple sub-queues queues for DF traffic class, one queue for each DF
       provisioned flow

    Flow here represents macro definition, it does not have to be only
    5-tuple. micro-flow

   Any chosen DF scheduling implementation MUST MAY run traffic conditioning
   at enqueue to decide if packets to be enqueued or discarded. Traffic Conditioning,
   as described in earlier section.  Discussed more in later section.

      1) Single queue to buffer all DF traffic

   This one single queue maintains, possibly a circular, indexed buffer
   list.  Each index logically maps to each scheduled time service.  If enqueue
   conditioning results in not to discard a packet, packet gets en-queued en-
   queued at a relevant index in the buffer list that maps to a relevant
   scheduled time slot.  If there is no packet(s) received for a
   specific scheduled time service then then buffer index for that scheduled
   service remains empty.  This also means that during dequeue, at a
   schedule time service, an empty index results in no dequeued packets
   from the DF queue and thus nothing to be transmitted from the DF
   queue at that point in time.  Queuing system may de-queue packets
   from non-DF queues when an index in DF buffer list found to be an
   empty during a specific scheduled time service.

                                              .
                                              |`.
       EF (Low latency) ----------------||---->  `.
                                       High   |    `.
                    .                         |      `.
       rate queues  |`.                       |        `.
       AF1 ----||--->  `.                     |          `.
                    |    `.                   |            `.
       AF3 ----||--->      '------------------>              '------>
                    |     .'            Low   |            .'
       BE  ----||--->   .'                    |          .'
                    | .'                      |        .'
                    .'                        |      .'
                                 Deterministic|    .'
       DF               ----------------||---->  .'
    (scheduled time/interrupt driven de-queue)|.'

      2) multiple queues to buffer each DF traffic flows

   If enqueue conditioning decides results in not to discard a packet, packet gets
   enqueued in the relevant DF sub-queue queue designated for that flow.  At a
   scheduled time slot, scheduler dequeues a packet from the respective
   sub-queue.
   queue for that flow.  Every scheduled time service interrupt is
   mapped to a flow specific DF sub-queue queue to dequeue a packet from.

                                              .
                                              |`.
       EF (Low latency) ----------------||---->  `.
                                       High   |    `.
                    .                         |      `.
       rate queues  |`.                       |        `.
       AF1 ----||--->  `.                     |          `.
                    |    `.                   |            `.
       AF3 ----||--->      '------------------>              '------>
                    |     .'            Low   |            .'
       BE  ----||--->   .'                    |          .'
                    | .'                      |        .'
                    .'                        |      .'
       (DF queues)               Deterministic|    .'
       DF (at interval 1, 6, 11 ..) ----||---->  .'
       DF (at interval 3, 8, 13 ..) ----||---->.'
    (scheduled time/interrupt driven de-queue)|

3.2.  Conditioning DF traffic at Enqueue

   DF traffic MUST be conditioned at the enqueue.  As per PHB
   definition, packets are required to be scheduled and delivered at a
   precise absolute or relative time interval.  Any packet that has
   missed the window of its service time MUST be discarded.  That would
   also mean any packet coming from the previous hop MUST be conditioned
   at the enqueue for validity of its scheduled service.  For example if
   a DF queue is provisioned to serve a packet with less than x ms of
   jitter and for an arrived packet, if next scheduled time for a packet
   results in more than x ms of jitter then such packet MUST be
   discarded.  The enqueued packet MUST also be checked against the size
   of the data.  If size of the data to be enqueued in a DF queue is
   bigger than what scheduled time slot is provisioned for then such
   packet MUST be discarded.

4.  Diffserv behavior through non-DF DS domains

   In cases where DF traffic is forwarded through multiple DS domains,
   DS domains close to the source and receiver understand application's
   deterministic service requirement well and so MUST be provisioned for
   the precise time scheduled forwarding treatment.  Intermediate DS
   domains MAY support DF PHB.  Intermediate domains that can not
   support DF PHB, DF traffic from such domains SHOULD get EF treatment,
   as defined in RFC5127 for Real Time Service aggregation.  Sender and
   Receiver DS domains, in such cases, MUST condition DF traffic at the
   respective Edge.  If EF service through intermediate DS domains can
   have a predictable upper bound, receiver DS domain Edge can add a
   correction to an incurred latency/jitter with its own defined time
   interval for DF service.

5.

7.  Updates to RFC4594 and RFC5127

   This specification updates RFC4594 with an addition of a new Diffserv
   Class.  It also updates RFC5127 to aggregate DF class of traffic to
   Real Time Aggregation Class.

6.

8.  IANA Considerations

   This document defines a new DSCP code-point DF.  IANA maintains the
   list of existing DSCPs.  Proposal is to allocate a new one for the DF
   code-point.

7.

9.  Security Considerations

   There is no security considerations required besides ones already
   understood in the context of Differentiated services architecture

8.

10.  Acknowledgements

   Fred Baker and Baker, Norm Finn.

9. Finn, David Black, Brian Carpenter for their
   comments and feed-back.

11.  References

9.1.

11.1.  Normative References

   [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, December
              1998.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC2598]  Jacobson, V., Nichols, K., and K. Poduri, "An Expedited
              Forwarding PHB", RFC 2598, June 1999.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594, August
              2006.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              Diffserv Service Classes", RFC 5127, February 2008.

9.2.

11.2.  Informative References

   [TiSCH]    Thubert, P., Watteyne, T., and R. Assimiti, "An
              Architecture for IPv6 over the TSCH mode of IEEE
              802.15.4e, I-D.draft-ietf-6tisch-architecture", Nov 2013.

   [LLN-DIFF]
              Shah, S. and P. Thubert, "Differentiated Service Class
              Recommendations for LLN Traffic,
              I-D.draft-svshah-tsvwg-lln-diffserv-recommendations", I-D.draft-svshah-tsvwg-
              lln-diffserv-recommendations", Aug 2013.

Authors' Addresses

   Shitanshu Shah
   Cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134
   US

   Email: svshah@cisco.com

   Pascal Thubert
   Cisco Systems
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Email: pthubert@cisco.com