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]