Skip to main content

Scheduling Function One (SF1) for hop-by-hop Scheduling in 6tisch Networks
draft-satish-6tisch-6top-sf1-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Satish Anamalamudi , Mingui Zhang , Charles E. Perkins , S.V.R Anand
Last updated 2016-06-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-satish-6tisch-6top-sf1-00
6tisch                                                    S. Anamalamudi
Internet-Draft                                                  M. Zhang
Intended status: Standards Track                     Huawei Technologies
Expires: December 8, 2016                                     C. Perkins
                                                               Futurewei
                                                             S.V.R.Anand
                                             Indian Institute of Science
                                                           June 06, 2016

   Scheduling Function One (SF1) for hop-by-hop Scheduling in 6tisch
                                Networks
                    draft-satish-6tisch-6top-sf1-00

Abstract

   This document defines a 6top Scheduling Function called "Scheduling
   Function One" (SF1) to schedule end-to-end dedicated L2-bundles hop-
   by-hop for each instance.  In addition, SF1 dynamically adapts the
   number of reserved cells in scheduled end-to-end L2-bundles of an
   ongoing instance through a Resource Reservation Protocol.  SF1 uses
   the 6P signaling messages with a TrackID to add/delete cells in end-
   to-end L2-bundles of each instance.

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 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 December 8, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Anamalamudi, et al.     Expires December 8, 2016                [Page 1]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  End-to-end Track formation with paired L2-bundles . . . . . .   3
   3.  Scheduling Function Identifier  . . . . . . . . . . . . . . .   5
   4.  Rules to Create, Add/Delete Cells in end-to-end L2-bundles  .   5
     4.1.  SF1 Triggering Events . . . . . . . . . . . . . . . . . .   5
     4.2.  SF1 Bandwidth Allocation  . . . . . . . . . . . . . . . .   6
     4.3.  SF1 Allocation policy . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  References  . . . . . . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   With Scheduling Function Zero (SF0), on-the-fly cell scheduling (ADD/
   DELETE) to 1-hop neighbors can be achieved for aggregated (best-
   effort) traffic flows.  In other words, all the instances from nodeA
   to nodeB in Fig. 1 are scheduled in a single L3-bundle (IP link).

                  L3-bundle(Instance-1,Instance-2,...Instance-n)
               ------------------------------------------------->
         nodeA<-------------------------------------------------  nodeB
                  L3-bundle(Instance-1,Instance-2,...Instance-n)

    Figure 1: L3-bundle for aggregated traffic flows in 1-hop with SF0.

   Some applications (e.g.  Industrial M2M) require end-to-end dedicated
   L2-bundles to protect the control/data streams for time-critical
   applications [I-D.ietf-detnet-use-cases].  For such applications,
   per-instance L2-bundles need to be scheduled hop-by-hop between
   source and destination nodes [I-D.ietf-6tisch-architecture].  In
   addition, cells in the scheduled end-to-end L2-bundles of each
   instance have to be dynamically adapted for bursty time-critical
   traffic flows.  To achieve, end-to-end tracks have to be installed
   with local TrackIDs that are associated with the L2-bundles of each
   instance.  With 1-hop based SF0 cell scheduling, it is difficult to

Anamalamudi, et al.     Expires December 8, 2016                [Page 2]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

   schedule dedicated end-to-end cells for isolated traffic flows.  In
   addition, global bandwidth estimation is required for dynamic
   bandwidth adaptation in multi-hop cell scheduling.  This draft
   proposes Scheduling Function One (SF1) to schedule end-to-end
   dedicated L2-bundles for each instance, and to dynamically adapt the
   cells in scheduled L2-bundles of ongoing instance.  (see Fig. 2).

                L2-bundle(Instance-1)       L2-bundle(Instance-1)
             ----------------------->      ------------------>
            <------------------------      <-------------------
                L2-bundle(Instance-1)       L2-bundle(Instance-1)

                L2-bundle(Instance-2)       L2-bundle(Instance-2)
             ---------------------->       ----------------->
      Source<-----------------------nodeB <----------------- Destination
                L2-bundle(Instance-2)      L2-bundle(Instance-2)
                        .                          .
                        .                          .
                L2-bundle(Instance-n)      L2-bundle(Instance-n)
             ----------------------->     -------------------->
            <------------------------     <--------------------
                L2-bundle(Instance-n)      L2-bundle(Instance-n)

   Figure 2: Dedicated L2-bundles for end-to-end isolated traffic flows
                                 with SF1

   The main objective of SF1 is to determine when to schedule the end-
   to-end L2-bundles for each instance, how to associate the TrackID for
   each L2-bundle, and when to dynamically adapt the cells in ongoing
   instances of end-to-end L2-bundles.

2.  End-to-end Track formation with paired L2-bundles

   In this specification, an end-to-end route path is assumed to be
   available with reactive P2P-RPL (Storing or non-storing mode)
   protocols.  In addition, resource reservation for the discovered-path
   is assumed to be available through Resource Reservation Protocol
   (RSVP)[RFC3209].

   For constrained based 6tisch networks, a new distributed light-weight
   based resource reservation (RSVP-TE-lite) protocol need to be
   proposed for end-to-end cell scheduling.  The alternative approach to
   reserve the end-to-end resources is by implementing the RSVP-TE
   protocol in centralized PCE and allocate the required bandwidth and
   chunk information through CoAP messages.  How exactly the end-to-end
   resources are reserved is out-of-scope in this document.

Anamalamudi, et al.     Expires December 8, 2016                [Page 3]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

   How exactly the reserved resources are going to be scheduled for end-
   to-end path of each instance with 6P protocol is defined with SF1.
   Once the required bandwidth for new instance is known through
   Resource Reservation Protocol [RFC3209], SF1 allocates the cells for
   the new instance through SF1 allocation policy (See Section 4.3).  An
   aggregation of cells is called "bundle"(the directional link to a
   next-hop neighbor).  Every L2-bundle is associated with a trackID to
   dynamically adapt the cells to an instance.  In addition, the TrackID
   at every node is used to identify the flow from a specific sender.
   The node that initiates the instance is called the owner of the
   Track.  As shown in Fig. 2, the SF1 running on the source node
   schedules the 6top transactions to a next-hop neighbor (nodeB) with a
   IPv6 header and RPL Packet Information (RPI) [RFC6553].  The local
   TrackID generated by the source is transmitted in a metadata field of
   6P transactions [I-D.ietf-6tisch-6top-protocol] to a next-hop
   neighbor (nodeB in Fig. 2).  Once the 6P transaction is successful
   between source and its next-hop neighbor (nodeB), a L2-bundle is
   created with the associated TrackID.  Subsequently, the SF1 running
   on the next-hop neighbor (nodeB) re-schedules the 6top transactions
   to the destination with an IPv6 header and the RPL Packet Information
   [RFC6553].  A new local TrackID is generated by the SF1 running on
   the next-hop (nodeB) and transmitted in the metadata field of 6P
   transactions to the destination.  The end-to-end Track is installed
   with a succession of paired L2-bundles (a receive bundle from the
   previous hop and a transmit bundle to the next hop) for a specific
   instance from source to destination.  During data transmission, SF1
   of Source at 6top identifies the TrackID based on "Source IP address,
   RPLInstanceID" from the received packet.  Subsequently, an associated
   L2-bundle is scheduled to forward the data to next-hop neighbor
   (nodeB).  Later, SF1 of the next-hop neighbor identifies the local
   TrackID based on "Source IP address, RPLInstanceID" of the received
   data to switch the track towards Destination.  With this, end-to-end
   data transmission is achieved through "Track forwarding" at the 6top
   sub-layer (see Fig. 4).  With Generalized Multi-protocol label
   switching (G-MPLS) [RFC3945], cells in paired L2-bundles are used as
   an implicit labels to label switch the data from Source to
   Destination at the 6top sub-layer.  The specific labelling method is
   out of scope in this specification.

Anamalamudi, et al.     Expires December 8, 2016                [Page 4]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

          +--------------+  <-Data transmission in end-to-end Track->
          |     IPv6     | Source                            Destination
          +--------------+   |                                     |
          |   6LoWPAN    |   |                                     |
          +--------------+   |                 nodeB               |
          |     6top     |   |                +----+               |
          +--------------+   |                |    |               |
          |   TSCH MAC   |   |                |    |               |
          +--------------+   |                |    |               |
          |   LLN PHY    |   |   L2-Bundle    |    |   L2-Bundle   |
          +--------------+   +----------------+    +---------------+
                             <--Dedicated cells for each Instance-->

         Figure 3: End-to-end cell scheduling with SF1 Scheduling

3.  Scheduling Function Identifier

   The Scheduling Function Identifier (SFID) of SF1 is
   IANA_SFID_SF1(TBD).

4.  Rules to Create, Add/Delete Cells in end-to-end L2-bundles

   With SF1, source node determines when to create end-to-end L2-bundles
   for new instance and when to add/delete cells in L2-bundles of
   ongoing instance in a three-step process:

   1.  Source node waits for a triggering event (Section 4.1).

   2.  Source node gets the required bandwidth information for a new
       Instance from Resource Reservation Protocol[RFC3209].  In
       addition, the Source node will dynamically adapt the bandwidth to
       end-to-end L2-bundles of ongoing instance through Resource
       Reservation Protocol (Section 4.2).

   3.  Based on admission control of Resource Reservation protocol, SF1
       allocation policy will determine the number of cells to add/
       delete in an end-to-end L2-bundle of an ongoing Instance
       (Section 4.3).

4.1.  SF1 Triggering Events

   The triggering events in SF1 are as follows :

   1.  If Source node has any Outgoing Bandwidth Requirement for new
       instance to transmit data to Destination(OB.Instance).

   2.  If Source node has a New Outgoing Bandwidth Requirement for
       Ongoing Instance to transmit data to Destination(NOB.Instance).

Anamalamudi, et al.     Expires December 8, 2016                [Page 5]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

   This allows SF1 to be triggered by new instance or change in
   scheduled bandwidth of ongoing instance.  The exact mechanism of when
   SF1 is triggered is implementation-specific.  It is noteworthy that
   cells are going to be used as implicit labels for G-MPLS label
   switching.  Hence, the dynamic adoption (OTF) of cells should be
   always triggered by the Source node.  In other words, intermediate
   nodes are not able to dynamically adapt(add/delete) the cells in an
   ongoing instance.

4.2.  SF1 Bandwidth Allocation

   SF1 need to support bandwidth allocation for two cases namely (i).New
   Instance and (ii).Ongoing Instance.

   o  Bandwidth allocation for New Instance:

   With RSVP-TE[RFC3209] admission control, SF1 gets the allocated
   bandwidth for the New Instance.  Subsequently, it includes the
   Scheduled Bandwidth(SB.Instance) into the SF1 allocation policy
   (Section 4.3).

   1.  Obtain Outgoing Bandwidth requirement for new Instance
       (OB.Instance): Assign OB.NewInstance from SB.NewInstance.

   2.  Map OB.NewInstance to required number of cells(NumCells).

   3.  Once the Instance is scheduled then the dynamic cell adaptation
       is through "Bandwidth adaptation of ongoing Instance" as follows.

   o  Bandwidth adoption for ongoing Instance:

   SF0 defines local Bandwidth Estimation Algorithm to dynamically adapt
   the cells with 1-hop neighbor nodes.  But, dynamic cell adoption in
   SF1 needs to have global bandwidth information to dynamically adapt
   the cells in end-to-end L2-bundles of each instance.  By way of Re-
   routing Traffic through make-before-break operation in RSVP-
   TE[RFC3209], bandwidth can be dynamically increased in end-to-end
   L2-bundles of Label-switched Path (LSPs).  Whenever dynamic bandwidth
   allocation is not possible in current labeling then ongoing end-to-
   end traffic is re-scheduled into new LSPs that are created with make-
   before-break operation.

   1.  Obtain the Increased Bandwidth Information (IB.Instance) from
       make-before-break operation.

   2.  Obtain New Scheduled Bandwidth (NSB.Instance) by adding
       IB.Instance to SB.instance in SF1 allocation policy (NSB.Instance
       = SB.instance+IB.Instance).

Anamalamudi, et al.     Expires December 8, 2016                [Page 6]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

   3.  Obtain New outgoing Bandwidth requirement for Instance
       (NOB.Instance).  Assign NOB.NewInstance from NSB.NewInstance.

   4.  Map NOB.NewInstance to required number of cells(NumCells).

   5.  Submit the request to the allocation policy.

   6.  Return to step 1 and wait for a triggering event.

4.3.  SF1 Allocation policy

   Based on the allocated bandwidth from Admission Control of RSVP-TE,
   the SF1 allocation policy will schedule the bandwidth and cells to a
   new Instance or Ongoing Instance.  The "Allocation Policy" is the set
   of rules used by SF1 to decide when to schedule bandwidth for a new
   instance, and when to add/delete cells to a particular L2-bundle to
   satisfy the bandwidth requirements of an ongoing Instance.  The
   operation of SF1 allocation policy to schedule bandwidth (obtained
   from Admission Control) and add/delete cells is similar to SF0 but
   specific to L2-bundle of each instance that is shown in Figure 4.

Anamalamudi, et al.     Expires December 8, 2016                [Page 7]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

                +----+---+---+---+---+--+--+---+---+---+
                |Resource Reservation Admission Control|
                +----+---+---+---+---+--+--+---+---+---+
                                    |
                                    |
                                   \|/
               SCHEDULED BANDWIDTH TO NEXT-HOP NEIGHBOR NODE
        <---------------------------------------------------------->
        +---+---+---+---+---+---+---+---+---+            +---+---+---+
        |INSTANCE-1 |INSTANCE-2 |INSTANCE-3 |........... |INSTANCE-N |
        +---+---+---+---+-+-+---+---+---+---+            +---+---+---+
                          |
                          |
                         \|/
             SCHEDULEDCELLS OF INSTANCE-2
          <-------------------------------- >
         +---+---+---+---+---+---+---+---+---+
         |   |   |   |   |   |   |   |   |   |
         +---+---+---+---+---+---+---+---+---+
                         |<----------------->|
                         |     SF1THRESH     |
                         |                   |
         REQUIREDCELLS   |                   |
         +---+---+       |                   |       DELETE
         |   |   |       |                   |       ONE/MORE
         +---+---+       |                   |       CELLS
                         |                   |
             REQUIREDCELLS                   |
         +---+---+---+---+---+---+           |       DO
         |   |   |   |   |   |   |           |       NOTHING
         +---+---+---+---+---+---+           |
                         |                   |
                     REQUIREDCELLS           |
         +---+---+---+---+---+---+---+---+---+---+   ADD
         |   |   |   |   |   |   |   |   |   |   |   ONE/MORE
         +---+---+---+---+---+---+---+---+---+---+   CELLS

                      Figure 4: SF1 Allocation Policy

5.  IANA Considerations

   IANA is requested to allocate a new Scheduling Function
   (IANA_SFID_SF1) from the SF space of Scheduling Functions defined in
   [I-D.dujovne-6tisch-6top-sf0]

Anamalamudi, et al.     Expires December 8, 2016                [Page 8]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

6.  Security Considerations

   TODO

7.  References

7.1.  References

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Architecture", RFC 3945,
              DOI 10.17487/RFC3945, October 2004,
              <http://www.rfc-editor.org/info/rfc3945>.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553,
              DOI 10.17487/RFC6553, March 2012,
              <http://www.rfc-editor.org/info/rfc6553>.

7.2.  Informative References

   [I-D.dujovne-6tisch-6top-sf0]
              Dujovne, D., Grieco, L., Palattella, M., and N. Accettura,
              "6TiSCH 6top Scheduling Function Zero (SF0)", draft-
              dujovne-6tisch-6top-sf0-01 (work in progress), March 2016.

   [I-D.ietf-6tisch-6top-protocol]
              Wang, Q. and X. Vilajosana, "6top Protocol (6P)", draft-
              ietf-6tisch-6top-protocol-00 (work in progress), April
              2016.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-09 (work
              in progress), November 2015.

   [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., and J. Schmitt,
              "Deterministic Networking Use Cases", draft-ietf-detnet-
              use-cases-09 (work in progress), March 2016.

Anamalamudi, et al.     Expires December 8, 2016                [Page 9]
Internet-Draft        draft-satish-6tisch-6top-sf1             June 2016

Authors' Addresses

   Satish Anamalamudi
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: satish.anamalamudi@huawei.com

   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District
   Beijing  100095
   China

   Email: zhangmingui@huawei.com

   Charles E. Perkins
   Futurewei
   2330 Central Expressway
   Santa Clara  95050
   Unites States

   Email: charliep@computer.org

   S.V.R Anand
   Indian Institute of Science
   Bangalore
   560012
   India

   Email: anand@ece.iisc.ernet.in

Anamalamudi, et al.     Expires December 8, 2016               [Page 10]