User Tools

Site Tools


group_update_based_on_ipv6_multicasting

Introduction

The group update based on IPv6 multicasting can be used to update several IoTivity devices at once (cf. similar to RFC 7390). The main benefits are that for large groups then number of messages can be reduced and also the latency until all group members receive an update is reduced compared to using unicast messages. Dedicated transient link-local or site-local IPv6 addresses can be associated with groups of IoTivity devices.

The main parts of this proposal cover:

  • Commissioning/address assignment
  • Group update messages
  • IPv4 support
  • Reliable multicasts
  • References

Commissioning/address assignment

The entity who keeps track of the assigened IPv6 multicast address is kept out of this proposal. Address assignment is done in a commissioning phase and the addressing information can be kept in a local resource directory (RD) or an IoT hub (cf. similar to RFC 7390).

Required IoTivity modifications:

  • New interface type to manage the address assignment “group.update.mgmt”
  • Payload of requests contains the desired IPv6 multicast address for the group and optionally an attribute name
  • Default handler can be provided for this interface type and manage address assignment and removal (POST, DELETE)
  • API to join and leave a group for a resource
  • Transient IPv6 multicast address is assigned on several resources to form a specific group
  • For the assignment unicast messages are used to configure group members

The device keeps a data structure to map group addresses to local resources and optionally to their attribute values.

Code modifications:

  • ocgroupaddress.c (new) contains the code to handle address assignments. stack is modified to forward requests to the default handler.
  • ocstack.h offers an API to let a resource join/leave an arbitrary IPv6 multicast address

ocstack.h

OCStackResult OCJoinGroup(OCResourceHandle *handle,
                         OCGroupIdentifier identifer);

OCStackResult OCLeaveGroup(OCResourceHandle *handle,
	OCGroupIdentifier identifier);

octypes.h

typedef enum
{
    OC_GRP_ID_IPV6_MULTICAST
} OCGroupIdentiferType;

typedef struct
{
    /** Action associated with observation request.*/
    OCGroupIdentiferType groupType;

    /** Arbitrary identifier (max 16 bytes).*/
    uint8_t identifier[16];
} OCGroupIdentifer;

Interaction:

Group update messages

A non-confirmable message can be used to update multiple CoAP devices at once. For heterogeneous resources, generic type specific attribute names are used.

Required IoTivity modification:

  • UDP socket has to join IPv6 multicast addresses
  • Address information is added to the request information
  • Lookup of resource
  • Optionally lookup of resource attribute
  • Dispatch update message

Code:

  • OCServerRequest need to carry the information for the target IPv6 multicast address
  • caipserver extract target IPv6 multicast address and provide information for further stack processing

IPv4 support

  • Use a single IPv4 multicast address for all groups, e.g. all CoAP nodes with 224.0.1.187
  • Assign a unique group identifier in the path, e.g. /grp/<GRP_IDENTIFIER>, use the last 8 octets of the IPv6 multicast address that would be used. In this way a mixed scenario with IPv4 and IPv6 can be realized.

Reliable multicasting

Definition: Eventual delivery of all the data to all the group members, without enforcing any particular delivery order.

Option 1 (positive acknowledgement): Sender has knowledge about group members and counts number of ACK messages. If not enough ACKs are received, the message is re-transmitted with exponential back-off. After maximum number of re-tries application is notified of not successful delivery.

Option 2 (negative acknowledgement): Sender transmits confirmable multicast message with increasing sequence number. If NACK is received, messages since the NACK and current sequence number are retransmitted.

group_update_based_on_ipv6_multicasting.txt · Last modified: 2016/03/01 05:36 by Markus Jung