RFC 8480
6TiSCH Operation Sublayer (6top) Protocol (6P)
Pages: 50
Proposed Standard
Proposed Standard
Part 4 of 4 – Pages 43 to 50
6. IANA Considerations
6.1. IETF IE Subtype 6P
This document adds the following number to the "IEEE Std 802.15.4 IETF IE Subtype IDs" registry defined by [RFC8137]: +--------+------------+-----------+ | Value | Subtype ID | Reference | +--------+------------+-----------+ | 1 | SUBID_6TOP | RFC 8480 | +---------------------+-----------+ Figure 34: IETF IE Subtype SUBID_6TOP6.2. 6TiSCH Parameters Subregistries
This section defines subregistries within the "IPv6 Over the TSCH Mode of IEEE 802.15.4e (6TiSCH)" parameters registry, hereafter referred to as the "6TiSCH parameters" registry. Each subregistry is described in a subsection.6.2.1. 6P Version Numbers
The name of the subregistry is "6P Version Numbers". The following note is included in this registry: "In the 6top Protocol (6P) [RFC8480], there is a field to identify the version of the protocol. This field is 4 bits in size." Each entry in the subregistry must include the version in the range 0-15 and a reference to the 6P version's documentation. The initial entry in this subregistry is as follows: +---------+-----------+ | Version | Reference | +---------+-----------+ | 0 | RFC 8480 | +---------+-----------+ Figure 35: 6P Version Number Entry All other version numbers are Unassigned. The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
6.2.2. 6P Message Types
The name of the subregistry is "6P Message Types". The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the type of message. This field is 2 bits in size." Each entry in the subregistry must include the message type in the range b00-b11, the corresponding name, and a reference to the 6P message type's documentation. Initial entries in this subregistry are as follows: +------+--------------+-----------+ | Type | Name | Reference | +------+--------------+-----------+ | b00 | REQUEST | RFC 8480 | | b01 | RESPONSE | RFC 8480 | | b10 | CONFIRMATION | RFC 8480 | +------+--------------+-----------+ Figure 36: 6P Message Types All other message types are Unassigned. The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].6.2.3. 6P Command Identifiers
The name of the subregistry is "6P Command Identifiers". The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Request, the value of this Code field is used to identify the command." Each entry in the subregistry must include an identifier in the range 0-255, the corresponding name, and a reference to the 6P command identifier's documentation.
Initial entries in this subregistry are as follows: +------------+------------+-----------+ | Identifier | Name | Reference | +------------+------------+-----------+ | 0 | Reserved | RFC 8480 | | 1 | ADD | RFC 8480 | | 2 | DELETE | RFC 8480 | | 3 | RELOCATE | RFC 8480 | | 4 | COUNT | RFC 8480 | | 5 | LIST | RFC 8480 | | 6 | SIGNAL | RFC 8480 | | 7 | CLEAR | RFC 8480 | | 8-254 | Unassigned | | | 255 | Reserved | RFC 8480 | +------------+------------+-----------+ Figure 37: 6P Command Identifiers The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].6.2.4. 6P Return Codes
The name of the subregistry is "6P Return Codes". The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a Code field that is 8 bits in size. In a 6P Response or 6P Confirmation, the value of this Code field is used to identify the return code." Each entry in the subregistry must include a return code in the range 0-255, the corresponding name, the corresponding description, and a reference to the 6P return code's documentation. If the return code corresponds to a Response error, the "Is Error?" entry must indicate "Yes". Otherwise, "No" must be used.
Initial entries in this subregistry are as follows: +------+-----------------+---------------------------+-----------+ | Code | Name | Description | Is Error? | +------+-----------------+---------------------------+-----------+ | 0 | RC_SUCCESS | operation succeeded | No | | 1 | RC_EOL | end of list | No | | 2 | RC_ERR | generic error | Yes | | 3 | RC_RESET | critical error, reset | Yes | | 4 | RC_ERR_VERSION | unsupported 6P version | Yes | | 5 | RC_ERR_SFID | unsupported SFID | Yes | | 6 | RC_ERR_SEQNUM | schedule inconsistency | Yes | | 7 | RC_ERR_CELLLIST | cellList error | Yes | | 8 | RC_ERR_BUSY | busy | Yes | | 9 | RC_ERR_LOCKED | cells are locked | Yes | +------+-----------------+---------------------------+-----------+ Figure 38: 6P Return Codes All other message types are Unassigned. The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].6.2.5. 6P Scheduling Function Identifiers
The name of the subregistry is "6P Scheduling Function Identifiers". The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is a field to identify the Scheduling Function to handle the message. This field is 8 bits in size." Each entry in the subregistry must include an SFID in the range 0-255, the corresponding name, and a reference to the 6P Scheduling Function's documentation. There are currently no entries in this subregistry. +------+---------------------------------+--------------------------+ | SFID | Name | Reference | +------+---------------------------------+--------------------------+ | 0-255| Unassigned | | +------+---------------------------------+--------------------------+ Figure 39: SF Identifier (SFID) Entry All message types are Unassigned.
The IANA policy for future additions to this subregistry depends on the value of the SFID, as shown in Figure 40. These specifications must follow the guidelines of Section 4. +-----------+------------------------------+ | Range | Registration Procedures | +-----------+------------------------------+ | 0-127 | IETF Review or IESG Approval | | 128-255 | Expert Review | +-----------+------------------------------+ Figure 40: SF Identifier (SFID): Registration Procedure6.2.6. 6P CellOptions Bitmap
The name of the subregistry is "6P CellOptions Bitmap". The following note is included in this registry: "In version 0 of the 6top Protocol (6P) [RFC8480], there is an optional CellOptions field that is 8 bits in size." Each entry in the subregistry must include a bit position in the range 0-7, the corresponding name, and a reference to the bit's documentation. Initial entries in this subregistry are as follows: +-----+---------------+-----------+ | bit | Name | Reference | +-----+---------------+-----------+ | 0 | TX (Transmit) | RFC 8480 | | 1 | RX (Receive) | RFC 8480 | | 2 | SHARED | RFC 8480 | | 3-7 | Reserved | | +-----+---------------+-----------+ Figure 41: 6P CellOptions Bitmap All other message types are Unassigned. The IANA policy for future additions to this subregistry is "IETF Review" or "IESG Approval" as described in [RFC8126].
7. References
7.1. Normative References
[IEEE802154] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2017, <https://www.rfc-editor.org/info/rfc8137>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.7.2. Informative References
[CCM-Star] Struik, R., "Formal Specification of the CCM* Mode of Operation", IEEE P802.15-4/0537r2, September 2005. [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>. [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
Appendix A. Recommended Structure of an SF Specification
The following section structure for an SF document is RECOMMENDED: o Introduction o RFC 2119 Requirements Language (if applicable) o Scheduling Function Identifier o Rules for Adding/Deleting Cells o Rules for CellList o 6P Timeout Value o Rule for Ordering Cells o Meaning of the Metadata Field o Node Behavior at Boot o Schedule Inconsistency Handling o 6P Error Handling o Examples o Implementation Status o Security Considerations o IANA Considerations o Normative References (if applicable) o Informative References (if applicable)
Authors' Addresses
Qin Wang (editor) Univ. of Sci. and Tech. Beijing 30 Xueyuan Road Beijing, Hebei 100083 China Email: wangqin@ies.ustb.edu.cn Xavier Vilajosana Universitat Oberta de Catalunya 156 Rambla Poblenou Barcelona, Catalonia 08018 Spain Email: xvilajosana@uoc.edu Thomas Watteyne Analog Devices 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States of America Email: thomas.watteyne@analog.com