Dear all,
I have some question about the return code (mainly about the ERROR code) in 6p response packet define in the draft: https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02 In figure 7: https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02#section-4.2.4 Return Code Value Description +--------------+------------------------+---------------------------+ | RC_SUCCESS | IANA_6TOP_RC_SUCCESS | operation succeeded | +--------------+------------------------+---------------------------+ | RC_ERR_VER | IANA_6TOP_RC_ERR_VER | unsupported 6P version | +--------------+------------------------+---------------------------+ | RC_ERR_SFID | IANA_6TOP_RC_ERR_SFID | unsupported SFID | +--------------+------------------------+---------------------------+ | RC_ERR_GEN | IANA_6TOP_RC_ERR_GEN | schedule generation error | +--------------+------------------------+---------------------------+ | RC_ERR_BUSY | IANA_6TOP_RC_ERR_BUSY | handling previous request | +--------------+------------------------+---------------------------+ | RC_ERR_NORES | IANA_6TOP_RC_ERR_NORES | not enough resources | +--------------+------------------------+---------------------------+ | RC_ERR_RESET | IANA_6TOP_RC_ERR_RESET | abort 6P Transaction | +--------------+------------------------+---------------------------+ | RC_ERR | IANA_6TOP_RC_ERR | generic error | +--------------+------------------------+---------------------------+ | reserved | TODO-0xf | | +--------------+------------------------+---------------------------+ As it defined a lots of error return code and also it has generic error: RC_ERR. - When should the nodes use the generic RC_ERROR? I assume it indicates the request cells are not available (the cell is occupied already when adding OR can't find the cell when deleting)? - Also, if the 6p response has multiple cases matched (for example, the candidate cells are occupied RC_ERROR and also no enough resource ERROR_NORES...), which one should the mote choose? (add priority for the error code? at least we need a decision) Looking forward to talk to you during the meeting soon! Tengfei -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
