Scheduling Function One (SF1) for hop-by-hop Scheduling in 6tisch Networks
draft-satish-6tisch-6top-sf1-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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]