RFC 8480
6TiSCH Operation Sublayer (6top) Protocol (6P)
Pages: 50
Proposed Standard
Proposed Standard
Part 2 of 4 – Pages 17 to 31
3.3. 6P Commands and Operations
3.3.1. Adding Cells
Cells are added by using the 6P ADD command. The Type field (T) is set to REQUEST. The Code field is set to ADD. Figure 10 defines the format of a 6P ADD Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | NumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+- Figure 10: 6P ADD Request Format Metadata: Used as extra signaling to the SF. The contents of the Metadata field are an opaque set of bytes passed unmodified to the SF. The meaning of this field depends on the SF and is out of scope for this document. For example, Metadata can specify in which slotframe to add the cells. CellOptions: Indicates the options to associate with the cells to be added. If more than one cell is added (NumCells > 1), the same options are associated with each one. This necessarily means that if node A needs to add multiple cells with different options it needs to initiate multiple 6P ADD Transactions. NumCells: The number of additional cells node A wants to schedule to node B. CellList: A list of zero or multiple candidate cells. Its length is implicit and is determined by the Length field of the Payload IE header.
Figure 11 defines the format of a 6P ADD Response and Confirmation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+- Figure 11: 6P ADD Response and Confirmation Format CellList: A list of zero or more 6P Cells. Consider the topology in Figure 1; in this case, the SF on node A decides to add NumCells cells to node B. Node A's SF selects NumCandidate cells from its schedule. These are cells that are candidates to be scheduled with node B. The CellOptions field specifies the type of these cells. NumCandidate MUST be greater than or equal to NumCells. How many cells node A selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document. Node A sends a 6P ADD Request to node B that contains the CellOptions, the value of NumCells, and a selection of NumCandidate cells in the CellList. If the NumCandidate cells do not fit in a single packet, this operation MUST be split into multiple independent 6P ADD Requests, each for a subset of the number of cells that eventually need to be added. In the case of a 3-step transaction, the SF is responsible for ensuring that the returned Candidate CellList fits into the 6P Response. Upon receiving the request, node B checks to see whether the CellOptions are set to a valid value as noted by Figure 7. If this is not the case, a Response with code RC_ERR is returned. If the number of cells in the received CellList in node B is smaller than NumCells, node B MUST return a 6P Response with the RC_ERR_CELLLIST code. Otherwise, node B's SF verifies which of the cells in the CellList it can install in node B's schedule, following the specified CellOptions field. How that selection is done is specified in the SF and is out of scope for this document. The verification can succeed (NumCells cells from the CellList can be used), fail (none of the cells from the CellList can be used), or partially succeed (fewer than NumCells cells from the CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that were scheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed).
Upon receiving the response, node A adds the cells specified in the CellList according to the CellOptions field.3.3.2. Deleting Cells
Cells are deleted by using the 6P DELETE command. The Type field (T) is set to REQUEST. The Code field is set to DELETE. Figure 12 defines the format of a 6P DELETE Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | NumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+- Figure 12: 6P DELETE Request Format Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. CellOptions: Indicates the options that need to be associated with the cells to delete. Only cells matching the CellOptions can be deleted. NumCells: The number of cells from the specified CellList the sender wants to delete from the schedule of both sender and receiver. CellList: A list of zero or more 6P Cells. Its length is determined by the Length field of the Payload IE header.
Figure 13 defines the format of a 6P DELETE Response and Confirmation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+- Figure 13: 6P DELETE Response and Confirmation Format CellList: A list of zero or more 6P Cells. The behavior for deleting cells is equivalent to that of adding cells except that: o The nodes delete the cells they agree upon rather than adding them. o All cells in the CellList MUST already be scheduled between the two nodes and MUST match the CellOptions field. If node A puts cells in its CellList that are not already scheduled between the two nodes and match the CellOptions field, node B MUST reply with a RC_ERR_CELLLIST return code. o The CellList in a 6P Request (2-step transaction) or 6P Response (3-step transaction) MUST be empty, contain exactly NumCells cells, or contain more than NumCells cells. The case where the CellList is not empty but contains fewer than NumCells cells is not supported; the RC_ERR_CELLLIST code MUST be returned when the CellList contains fewer than NumCells cells. If the CellList is empty, the SF on the receiving node MUST choose NumCells cells scheduled to the sender matching the CellOptions field and delete them. If the CellList contains more than NumCells cells, the SF on the receiving node chooses exactly NumCells cells from the CellList to delete.
3.3.3. Relocating Cells
Cell relocation consists of moving a cell to a different [slotOffset,channelOffset] location in the schedule. The Type field (T) is set to REQUEST. The Code field is set to RELOCATE. Figure 14 defines the format of a 6P RELOCATE Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | NumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relocation CellList ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Candidate CellList ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 14: 6P RELOCATE Request Format Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. CellOptions: Indicates the options that need to be associated with cells to be relocated. NumCells: The number of cells to relocate. MUST be greater than or equal to 1. Relocation CellList: The list of NumCells 6P Cells to relocate. Candidate CellList: A list of NumCandidate candidate cells for node B to pick from. NumCandidate MUST be 0, equal to NumCells, or greater than NumCells. Its length is determined by the Length field of the Payload IE header. In a 2-step 6P RELOCATE Transaction, node A specifies both (1) the cells it needs to relocate and (2) the list of candidate cells to relocate to. The Relocation CellList MUST contain exactly NumCells entries. The Candidate CellList MUST contain at least NumCells entries (NumCandidate >= NumCells). In a 3-step 6P RELOCATE Transaction, node A specifies only the cells it needs to relocate -- not the list of candidate cells to relocate to. The Candidate CellList MUST therefore be empty.
Figure 15 defines the format of a 6P RELOCATE Response and Confirmation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+- Figure 15: 6P RELOCATE Response and Confirmation Format CellList: A list of zero or more 6P Cells. Node A's SF wants to relocate NumCells cells. Node A creates a 6P RELOCATE Request and indicates the cells it wants to relocate in the Relocation CellList. It also selects NumCandidate cells from its schedule as candidate cells to relocate the cells to, and it puts them in the Candidate CellList. The CellOptions field specifies the type of the cell(s) to relocate. NumCandidate MUST be greater than or equal to NumCells. How many cells it selects (NumCandidate) and how that selection is done are specified in the SF and are out of scope for this document. Node A sends the 6P RELOCATE Request to node B. Upon receiving the request, node B checks to see if the length of the Candidate CellList is greater than or equal to NumCells. Node B's SF verifies that all the cells in the Relocation CellList are scheduled with node A and are associated with the options specified in the CellOptions field. If either check fails, node B MUST send a 6P Response to node A with return code RC_ERR_CELLLIST. If both checks pass, node B's SF verifies which of the cells in the Candidate CellList it can install in its schedule. How that selection is done is specified in the SF and is out of scope for this document. That verification for the Candidate CellList can succeed (NumCells cells from the Candidate CellList can be used), fail (none of the cells from the Candidate CellList can be used), or partially succeed (fewer than NumCells cells from the Candidate CellList can be used). In all cases, node B MUST send a 6P Response that includes a return code set to RC_SUCCESS and that specifies the list of cells that will be rescheduled following the CellOptions field. That list can contain NumCells elements (succeed), 0 elements (fail), or between 0 and NumCells elements (partially succeed). If N < NumCells cells appear in the CellList, this means that the first N cells in the Relocation CellList have been relocated and the remainder have not.
Upon receiving the response with code RC_SUCCESS, node A relocates the cells specified in the Relocation CellList of its RELOCATE Request to the new locations specified in the CellList of the 6P Response, in the same order. If the received return code is RC_ERR_CELLLIST, the transaction is aborted and no cell is relocated. In the case of a 2-step transaction, node B relocates the selected cells upon receiving the link-layer ACK for the 6P Response. In the case of a 3-step transaction, node B relocates the selected cells upon receiving the 6P Confirmation. The SF SHOULD NOT relocate all cells between two nodes at the same time, as this might result in the schedules of both nodes diverging significantly. Figure 16 shows an example of a successful 2-step 6P RELOCATE Transaction. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P RELOCATE Request | | Type = REQUEST | | Code = RELOCATE | | SeqNum = 11 | | NumCells = 2 | | R.CellList = [(1,2),(2,2)] | | C.CellList = [(3,3),(4,3),(5,3)] | |-------------------------------------->| B prepares | L2 ACK | to relocate |<- - - - - - - - - - - - - - - - - - - | (1,2)->(5,3) | | and | | (2,2)->(3,3) | 6P Response | | Code = RC_SUCCESS | | SeqNum = 11 | | CellList = [(5,3),(3,3)] | A relocates |<--------------------------------------| (1,2)->(5,3) | L2 ACK | and | - - - - - - - - - - - - - - - - - - ->| B relocates (2,2)->(3,3) | | (1,2)->(5,3) | | and | | (2,2)->(3,3) Figure 16: Example of a Successful 2-Step 6P RELOCATE Transaction
Figure 17 shows an example of a partially successful 2-step 6P RELOCATE Transaction. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P RELOCATE Request | | Type = REQUEST | | Code = RELOCATE | | SeqNum = 199 | | NumCells = 2 | | R.CellList = [(1,2),(2,2)] | | C.CellList = [(3,3),(4,3),(5,3)] | B prepares |-------------------------------------->| to relocate | L2 ACK | (1,2)->(4,3) |<- - - - - - - - - - - - - - - - - - - | but cannot | | relocate (2,2) | 6P Response | | Type = RESPONSE | | Code = RC_SUCCESS | | SeqNum = 199 | | CellList = [(4,3)] | A relocates |<--------------------------------------| (1,2)->(4,3) | L2 ACK | | - - - - - - - - - - - - - - - - - - ->| B relocates | | (1,2)->(4,3) | | | | Figure 17: Example of a Partially Successful 2-Step 6P RELOCATE Transaction
Figure 18 shows an example of a failed 2-step 6P RELOCATE Transaction. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P RELOCATE Request | | Type = REQUEST | | Code = RELOCATE | | SeqNum = 53 | | NumCells = 2 | | R.CellList = [(1,2),(2,2)] | | C.CellList = [(3,3),(4,3),(5,3)] | |-------------------------------------->| B cannot | L2 ACK | relocate |<- - - - - - - - - - - - - - - - - - - | (1,2) | | or (2,2) | 6P Response | | Type = RESPONSE | | Code = RC_SUCCESS | | SeqNum = 53 | | CellList = [] | |<--------------------------------------| B does not | L2 ACK | relocate A does not | - - - - - - - - - - - - - - - - - - ->| relocate | | | | Figure 18: Failed 2-Step 6P RELOCATE Transaction Example
Figure 19 shows an example of a successful 3-step 6P RELOCATE Transaction. +----------+ +----------+ | Node A | | Node B | +----+-----+ +-----+----+ | | | 6P RELOCATE Request | | Type = REQUEST | | Code = RELOCATE | | SeqNum = 11 | | NumCells = 2 | | R.CellList = [(1,2),(2,2)] | | C.CellList = [] | |-------------------------------------->| | L2 ACK | |<- - - - - - - - - - - - - - - - - - - | B identifies | | candidate | | cells | 6P Response | (3,3), | Code = RC_SUCCESS | (4,3), and | SeqNum = 11 | (5,3) | CellList = [(3,3),(4,3),(5,3)] | A prepares |<--------------------------------------| to relocate | L2 ACK | (1,2)->(5,3) | - - - - - - - - - - - - - - - - - - ->| and | | (2,2)->(3,3) | 6P Confirmation | | Code = RC_SUCCESS | | SeqNum = 11 | | CellList = [(5,3),(3,3)] | |-------------------------------------->| B relocates | L2 ACK | (1,2)->(5,3) A relocates |<- - - - - - - - - - - - - - - - - - - | and (1,2)->(5,3) | | (2,2)->(3,3) and | | (2,2)->(3,3) | | | | Figure 19: Example of a Successful 3-Step 6P RELOCATE Transaction
3.3.4. Counting Cells
To retrieve the number of scheduled cells node A has with B, node A issues a 6P COUNT command. The Type field (T) is set to REQUEST. The Code field is set to COUNT. Figure 20 defines the format of a 6P COUNT Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: 6P COUNT Request Format Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. CellOptions: Specifies which type of cell to be counted. Figure 21 defines the format of a 6P COUNT Response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: 6P COUNT Response Format NumCells: The number of cells that correspond to the fields of the request. Node A issues a COUNT command to node B, specifying some cell options. Upon receiving the 6P COUNT Request, node B goes through its schedule and counts the number of cells scheduled with node A in its own schedule that match the cell options in the CellOptions field of the request. Section 3.2.3 details the use of the CellOptions field. Node B issues a 6P Response to node A with return code RC_SUCCESS and with NumCells containing the number of cells that match the request.
3.3.5. Listing Cells
To retrieve a list of scheduled cells node A has with node B, node A issues a 6P LIST command. The Type field (T) is set to REQUEST. The Code field is set to LIST. Figure 22 defines the format of a 6P LIST Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | CellOptions | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset | MaxNumCells | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 22: 6P LIST Request Format Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. CellOptions: Specifies which type of cell to be listed. Reserved: Reserved bits. These bits SHOULD be set to zero when sending the message and MUST be ignored upon reception. Offset: The offset of the first scheduled cell that is requested. The mechanism assumes that cells are ordered according to a rule defined in the SF. The rule MUST always order the cells in the same way. MaxNumCells: The maximum number of cells to be listed. Node B MAY return fewer than MaxNumCells cells -- for example, if MaxNumCells cells do not fit in the frame.
Figure 23 defines the format of a 6P LIST Response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CellList ... +-+-+-+-+-+-+-+-+- Figure 23: 6P LIST Response Format CellList: A list of zero or more 6P Cells. When receiving a LIST command, node B returns the cells scheduled with A in its schedule that match the CellOptions field as specified in Section 3.2.3. When node B receives a LIST Request, the returned CellList in the 6P Response contains between 0 and MaxNumCells cells, starting from the specified offset. Node B SHOULD include as many cells as will fit in the frame. If the response contains the last cell, node B MUST set the Code field in the response to RC_EOL ("End of List", as per Figure 38 in Section 6.2.4), indicating to node A that there are no more cells that match the request. Node B MUST return at least one cell, unless the specified offset is beyond the end of B's cell list in its schedule. If node B has fewer than Offset cells that match the request, node B returns an empty CellList and a Code field set to RC_EOL.
3.3.6. Clearing the Schedule
To clear the schedule between nodes A and B (for example, after a schedule inconsistency is detected), node A issues a CLEAR command. The Type field (T) is set to REQUEST. The Code field is set to CLEAR. Figure 24 defines the format of a 6P CLEAR Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 24: 6P CLEAR Request Format Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. Figure 25 defines the format of a 6P CLEAR Response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: 6P CLEAR Response Format When a 6P CLEAR command is issued from node A to node B, both nodes A and B MUST remove all the cells scheduled between them. That is, node A MUST remove all the cells scheduled with node B, and node B MUST remove all the cells scheduled with node A. In a 6P CLEAR command, the SeqNum MUST NOT be checked. In particular, even if the request contains a SeqNum value that would normally cause node B to detect a schedule inconsistency, the transaction MUST NOT be aborted. Upon 6P CLEAR completion, the value of SeqNum MUST be reset to 0. The return code sent in response to a 6P CLEAR command SHOULD be RC_SUCCESS unless the operation cannot be executed. When the CLEAR operation cannot be executed, the return code MUST be set to RC_RESET.
3.3.7. Generic Signaling between SFs
The 6P SIGNAL message allows the SF implementations on two neighbor nodes to exchange generic commands. The payload in a received SIGNAL message is an opaque set of bytes passed unmodified to the SF. The length of the payload is determined by the Length field of the Payload IE header. How the generic SIGNAL command is used is specified by the SF and is outside the scope of this document. The Type field (T) is set to REQUEST. The Code field is set to SIGNAL. Figure 26 defines the format of a 6P SIGNAL Request. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata | payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: 6P SIGNAL Request Format Metadata: Same usage as for the 6P ADD command; see Section 3.3.1. Its format is the same as that in the 6P ADD command, but its content could be different. Figure 27 defines the format of a 6P SIGNAL Response. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | SeqNum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: 6P SIGNAL Response Format
(page 31 continued on part 3)