6tisch S. Anamalamudi Internet-Draft Huaiyin Institute of Technology Intended status: Standards Track B. Liu Expires: April 30, 2018 M. Zhang Huawei Technologies AR. Sangi Huaiyin Institute of Technology C. Perkins Futurewei S.V.R.Anand Indian Institute of Science October 27, 2017 Scheduling Function One (SF1): hop-by-hop Scheduling with RSVP-TE in 6tisch Networks draft-satish-6tisch-6top-sf1-04 Abstract This document defines a 6top Scheduling Function called "Scheduling Function One" (SF1) to reserve, label and schedule the end-to-end resources hop-by-hop through the Resource ReserVation Protocol - Traffic Engineering (RSVP-TE). SF1 uses the 6P signaling messages with a global TrackID to add or delete the cells in L2-bundles of isolated traffic flows. 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 April 30, 2018. Anamalamudi, et al. Expires April 30, 2018 [Page 1] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 Copyright Notice Copyright (c) 2017 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 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. Operation of Scheduling Function One (SF1) . . . . . . . . . 4 2.1. End-to-end Operation . . . . . . . . . . . . . . . . . . 4 2.2. One-hop Operation . . . . . . . . . . . . . . . . . . . . 6 2.2.1. 3-step transaction . . . . . . . . . . . . . . . . . 6 2.2.2. 2-step transaction . . . . . . . . . . . . . . . . . 7 2.3. Reroute and Bandwidth Increase mechanism . . . . . . . . 8 2.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. RSVP-PATH message . . . . . . . . . . . . . . . . . . . . 9 3.2. RSVP-RESV message . . . . . . . . . . . . . . . . . . . . 10 4. Scheduling Function Identifier . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. References . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Scheduling Function Zero (SF0) [I-D.ietf-6tisch-6top-sf0] enables on- the-fly cell scheduling (ADD/DELETE) between one-hop neighbors for aggregated (best-effort) traffic flows. In other words, all the instances from nodeA to nodeB in Figure 1 are scheduled in a single L3-bundle (IP link). Anamalamudi, et al. Expires April 30, 2018 [Page 2] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 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 over one-hop with SF0. Some applications (e.g. Industrial M2M) require end-to-end dedicated L2-bundles to support control/data streams for time-critical applications [I-D.ietf-detnet-use-cases]. For such applications, the sender can reserve a dedicated track to the receiver for each isolated instance. A track is actually a succession of paired L2-bundles (a receive bundle at the downstream node and a transmit bundle at the upstream node), which is identified by a global TrackID. Per-instance L2-bundles need to be scheduled hop-by-hop in between sender and receiver [I-D.ietf-6tisch-architecture]. In addition, cells in the scheduled end-to-end track of each instance may have to be dynamically adapted for bursty time-critical traffic flows. With one-hop based SF0 cell scheduling, it is difficult to schedule dedicated end-to-end cells for isolated traffic flows. Moreover, global bandwidth estimation through Resource Reservation protocol is required for bandwidth allocation in multi-hop cell scheduling. This draft specifies a Scheduling Function One (SF1) to schedule end-to-end dedicated L2-bundles for each instance, and to dynamically adapt the cells in already scheduled L2-bundles through RSVP-TE (see Figure 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) ----------------------> -----------------> Sender<-----------------------nodeB <----------------- Receiver 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 Anamalamudi, et al. Expires April 30, 2018 [Page 3] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 2. Operation of Scheduling Function One (SF1) SF1 is a combination of RSVP-TE and 6P (the 6top protocol [I-D.ietf-6tisch-6top-protocol]). According to the bandwidth and QoS requirements of traffic flows, SF1 can schedule, reserve and label L2-bundles of cells at each hop, build up an end-to-end track identified by a global TrackID, and dynamically adapt the cells in an existing track. Using SF1, the Sender determines when to reserve end-to-end resources. The following events may trigger the use of SF1: o The Sender has an outgoing bandwidth requirement for a new instance to transmit data to Receiver. o The Sender has a new outgoing bandwidth requirement for an existing instance to transmit data to Receiver. In both cases, distributed RSVP-TE is used to provide end-to-end resource reservations along with scheduling operations. The outcome of RSVP-TE is a label switching path (LSP) [RFC3209]. In the context of this draft, a track is actually an LSP, in which the label at each hop is associated to the reserved cells. And the TrackID is equivalent to the LSP_ID. 2.1. End-to-end Operation PATH PATH PATH +-----------+ +-----------+ +-----------+ | | | | | | | v | v | v +--------+ +--------+ +--------+ +--------+ | Sender | | Node A | | Node B | |Receiver| +--------+ +--------+ +--------+ +--------+ ^ 6P | ^ 6P | ^ 6P | | Trans. | | Trans. | | Trans. | |<--------->| |<--------->| |<--------->| +-----------+ +-----------+ +-----------+ RESV RESV RESV Figure 3: End-to-end Operation in SF1 Anamalamudi, et al. Expires April 30, 2018 [Page 4] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 +--------+ +--------+ +--------+ | Sender |-----PATH----->|Receiver|-----RESV----->| Sender | +--------+ +--------+ +--------+ |----------E2E Track Reservation---------| |-----------------E2E Timeout---------------| Figure 4: End-to-end timeout in SF1 It is assumed that an end-to-end route path is already available, for instance by using AODV-RPL [I-D.ietf-roll-aodv-rpl] routing. To initiate the track reservation, the sender sends the RSVP-PATH message to the receiver along the route. The PATH message describes the characteristics of the traffic flow and gathers information along the route to help the receiver(s) construct an appropriate reservation request [RFC2205]. Upon arrival of the PATH message, the receiver sends an RSVP-RESV message upstream to the sender. At each hop, the cells to be reserved are negotiated between 2 neighbors with the help of 6P transactions. If one-hop reservation succeeds, the downstream node assigns a label, which is associated to the selected cells, to the upstream node. And the label is also associated to the track whose TrackID is encapsulated in the FILTER_SPEC of the RESV message. If one-hop reservation fails at an intermediate node, the node SHOULD send a ResvErr message to the receiver and all the nodes along the downstream route to tear down the reserved resources. When the RESV message arrives at the sender before the end-to-end timeout, an end-to-end track is built successfully. If no RESV message is received at the sender when timeout, the track reservation fails. The end-to-end data transmission is achieved through Track Forwarding [I-D.ietf-6tisch-architecture] that can be seen as a G-MPLS operation in which the explicit label at each hop is associated to an implicit label, i.e., the reserved cells. When transmitting data, the sender identifies the track to be used based on Sender and Receiver IP addresses and RPLInstanceID of the packet. At each hop, the packet is transmitted using the reserved L2-bundle of cells on this track. Anamalamudi, et al. Expires April 30, 2018 [Page 5] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 +--------------+ <-Data transmission in end-to-end Track-> | IPv6 | Sender Receiver +--------------+ | | | 6LoWPAN | | | +--------------+ | nodeB | | 6top | | +----+ | +--------------+ | | | | | TSCH MAC | | | | | +--------------+ | | | | | LLN PHY | | L2-Bundle | | L2-Bundle | +--------------+ +----------------+ +---------------+ <--Dedicated cells for each Instance--> Figure 5: Track Forwarding 2.2. One-hop Operation Upon arrival of the PATH message at an application receiver, the SENDER_TSPEC and ADSPEC objects are utilized to select the resource reservation parameters in FLOWSPEC of the RESV message. Since RSVP provides receiver initiated resource reservation setup, the scheduling operation proceeds upstream from receiver to sender. In 6P the resources are represented as cells, thus the bandwidth can be interpreted as the number of cells, and the QoS can be interpreted as the constraints on cells, e.g. the priority of slotframe, the slotOffset and channelOffset of cells. Therefore, the bandwidth and QoS parameters in FLOWSPEC need to be mapped to number and constraints of cells in the 6P transaction. In this document, when there are two neighbor nodes, the upstream node is named Node A, and the downstream node is named Node B. If Node B is the receiver, the cell reservation is initiated by the arrival of a PATH message. If node B is an intermediate node, the reservation is initiated by the arrival of an RESV message from downstream. The cell reservation begins with 6P transactions, which can be 3-step or 2-step [I-D.ietf-6tisch-6top-protocol]. The operation of RESV message with these two kinds of transactions is specified as follows. 2.2.1. 3-step transaction As illustrated in Figure 6, Node B first determines whether it can provide enough qualified cells to receive traffic from Node A, according to the parameters in FLOWSPEC. If not, Node B SHOULD send a ResvErr message. Otherwise, Node B transmits a 6P Request message to Node A with the slotFrame_ID in the metadata field. The type of the Request message (ADD or DELETE) is decided by comparing the the required cells and the currently reserved cells. In a 3-step Anamalamudi, et al. Expires April 30, 2018 [Page 6] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 transaction, the "CellList" field in the 6P request SHOULD be empty. The timeout for the 6P transaction is as defined in [I-D.ietf-6tisch-6top-protocol]. Node A checks the associated slotframe and proposes a candidate CellList. Then a 6P Response message is sent back to Node B. If Node B is able to select expected number of cells in this candidate CellList, it sends an RESV message to Node A, in which the 6P Confirmation message indicating the selected cells is encapsulated as the 6P OPERATION object, and the label is assigned as defined in Section 3.2. Otherwise, the Node B can choose to initiate another 6P transaction on another slotframe which can fulfill the QoS requirement. If all the 6P transactions fail, Node B SHOULD send a ResvErr message all the way to the receiver to tear down all the reserved resources. When the RESV message arrives at Node A, the L2-bundle between Node A and Node B is installed. Node A Node B -------------- -------------- | | FLOWSPEC: | | bandwidth and | | QoS requirements | | | | Map bandwidth | | and QoS to cells | 6P Request with | | an empty CellList | timeout |<--------------------------| --- | | | | 6P Response with | | timeout | candidate CellList | | --- |-------------------------->| X | | RESV carrying 6P | | | Confirmation with | | | selected CellList | X |<--------------------------|Cells reserved Cells reserved| | Label assigned| | Figure 6: Operation of RESV message with 3-step transaction. 2.2.2. 2-step transaction As illustrated in Figure 7, Node B SHOULD provide a candidate CellList which can fulfill the requirements in the 6P Request message, then Node A sends back the 6P Response message with a selected CellList. If the number of cells in the selected CellList is what Node B expects, Node B sends an RESV message to Node A including an assigned label and without the 6P OPERATION object. The Anamalamudi, et al. Expires April 30, 2018 [Page 7] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 error handling mechanism is the same as in the 3-step transaction fashion. Node A Node B -------------- -------------- | | FLOWSPEC: | | bandwidth and | | QoS requirements | | | | Map bandwidth and | | QoS to cells | 6P Request and | | candidate CellList | timeout |<--------------------------| --- | | | | 6P Response with | | timeout | selected CellList | | --- |-------------------------->| X | | | | | | | | RESV | X |<--------------------------|Cells reserved Cells reserved| | Label assigned| | Figure 7: Operation of RESV message with 2-step transaction. 2.3. Reroute and Bandwidth Increase mechanism Whenever the sender needs to establish a new tunnel that can maintain resource reservations without double counting (at any particular intermediate node) the resources with an existing tunnel, then the "RSVP reroute mechanism" is initiated [RFC3209]. With this operation, bandwidth can be increased or decreased end-to-end in the tunnel. The detailed explanation of the reroute mechanism is explained in [RFC3209]. 2.4. Error Codes The detailed explanation of PathErr and ResvErr with different ERROR_SPEC to handle Scheduling and 6P operation errors will be described in later specification. 3. Message Format Anamalamudi, et al. Expires April 30, 2018 [Page 8] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 3.1. RSVP-PATH message The basic RSVP-PATH message [RFC2205] is used to carry the "Sender Traffic Specification" along with "characterization parameters" from sender to receiver. Since RSVP treats objects as opaque data, it is permissible to use another protocol element (e.g. GMPLS, 6P, SF1) as an object in a RSVP-PATH message. The format of the PATH message that supports 6tisch scheduling capabilities (6P and SF1) is as follows: ::= [ ] [ [ | ] ... ] [ ] [ ] [ ] [ <6P OPERATION REQUEST> ] [ ] [ ] [ ] [ ... ] ::= [ ] [ ] The format of the Generalized Label Request Object in PATH message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Class-Num (19)| C-Type (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Generalized Label Request describes the requirement of communication characteristics to support the 6TiSCH-LSP being requested. The Generalized Label Request object is set by the ingress node (6LR), transparently passed by transit nodes, and used by the egress node (6LR). Anamalamudi, et al. Expires April 30, 2018 [Page 9] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 1. LSP Encoding Type (8 bits): Indicates the encoding of the LSP being requested. +---------+--------------+ | Value | Type | +---------+--------------+ | TBD | Timeslot | +---------+--------------+ 2. Switching Type (8 bits): Indicates the type of switching that should be performed on a particular link. +---------+-------------------------------------+ | Value | Type | +---------+-------------------------------------+ | 100 |Time-Division-Multiplex (TDM) Capable| +---------+-------------------------------------+ 3. G-PID (8 bits): An identifier of the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. +---------+-----------------------+------------+ | Value | Type | Technology | +---------+-----------------------+------------+ | TBD |Wireless PAN (802.15.4)| TSCH | +---------+-----------------------+------------+ "SF1 OPERATION REQUEST" and "6P OPERATION REQUEST" are added in the PATH message to check for 6tisch scheduling capabilities within the intermediate nodes from sender to receiver. The "Timeslot Switching Capability" (TSC) is used as an implicit label to switch the cell at intermediate nodes [RFC3473]. "LABEL_REQUEST" in path message should be set to "Timeslot Switching Capability". If an intermediate node does not support the TSC or "6P transactions" or "SF1 operation" then it MUST send a "PathErr" message back to application. At the sender, the combination of sender and receiver IP addresses and the RPLInstanceID is mapped to a 16-bit identifier. The sender uses this identifier as the Track ID, and encapsulates it in the SENDER_TEMPLATE. 3.2. RSVP-RESV message The basic RSVP-RESV messages [RFC2205] are transmitted upstream from receiver to sender to provide resource reservation as well as label distribution. In this specification, hop-by-hop scheduling is extended to support both resource reservation and label distribution. The current specification is only defined for unicast point-to-point traffic flows, i.e., Fixed Filter (FF) reservation style. Anamalamudi, et al. Expires April 30, 2018 [Page 10] Internet-Draft draft-satish-6tisch-6top-sf1 October 2017 The format of the RESV message that supports 6tisch scheduling capabilities (6P and SF1) is as follows: ::= [ ] [ [ | ] ... ] [ ] [ <6P OPERATION> ] [ ] [ ] [ ] [ ] [ ... ]