RFC 8480: 6TiSCH Operation Sublayer (6top) Protocol (6P)
In plain English — editorial summary, not part of the RFC
This document defines the "IPv6 over the TSCH mode of IEEE 802.15.4e" (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete Time-Slotted Channel Hopping (TSCH) cells to/on one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the layer just above the IEEE Std 802.15.4 TSCH Medium Access Control layer. 6top is composed of one or more Scheduling Functions (SFs) and the 6top Protocol defined in this document. A 6top SF decides when to add/delete cells, and it triggers 6P Transactions. The definition of SFs is out of scope for this document; however, this document provides the requirements for an SF.
Document record
- Document ID
- RFC8480
- Published
- November 2018
- Authors
- Q. Wang; X. Vilajosana; T. Watteyne
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- int
- Pages
- 50
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8467Padding Policies for Extension Mechanisms for DNS (EDNS(0))Current
October 2018
- RFC 8504IPv6 Node RequirementsCurrent
January 2019
- RFC 8505Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor DiscoveryUpdated
November 2018
- RFC 8513A YANG Data Model for Dual-Stack Lite (DS-Lite)Current
January 2019
- RFC 8425IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option FlagsCurrent
July 2018
- RFC 8539Softwire Provisioning Using DHCPv4 over DHCPv6Current
March 2019
- RFC 8415Dynamic Host Configuration Protocol for IPv6 (DHCPv6)Obsoleted
November 2018
- RFC 8389Definitions of Managed Objects for Mapping of Address and Port with Encapsulation (MAP-E)Current
December 2018
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?