This is an old revision of the document!
This proposal is to have a seamless communication between IoTivity devices over Heterogeneous connectivity. The requirement is to send IoTivity messages between client and server even though they are not directly connected by the same transport.
In the current IoTivitiy design, an OIC client can discover and communicate with any resource hosted by OIC server on same connectivity. For Ex: OIC Client can detect an OIC light resource when both are on same IP network or in each other's range via BT / BLE.
In the new proposal, if any Intermediary gateway device has multiple connectivity for ex: IP and BT, it can forward request's and responses so that resources on different transports can be discovered and communicated. This allows OIC clients to communicate with resource available on different connectivity.
For ex: An OIC client on IP network can discover a resource available on BT, if any intermediary gateway node having IP and BT can forward the messages.
To achieve the functionality, we propose to add a new CoAP option with details as follows:
Option Number: 65524 (Experimental, needs expert review before using vendor-specific option number)
Option Max Data Length: 20
Option Data Format: Binary
|1 byte||'len_src' bytes||1 byte||'len_dest' bytes||2 bytes|
In the proposal, OIC devices are classified into 3 categories:
1) Gateway (Use “ROUTING=GW” during compilation)
A gateway will generally have multiple connectivity and will act as intermediary, responsible for forwarding CoAP packets between different connectivity. Gateway’s are given unique ID’s for easy identification and tracking. This ID acts similar to prefixes in IPv6. A gateway can also optionally host or look out for any regular OIC resource across hops.
2) End device (Use “ROUTING=EP” during compilation)
An end device will not forward CoAP packets across different connectivity, but can look out for resources or make there resources available across hops with the help of Gateway's. End devices are identified by their MAC / IP addresses and will be only visible to border Gateway and not notified to Gateway’s across mesh. End devices are given ID’s by border gateway’s which will be unique to a Gateway and not in entire mesh. However a “Gateway ID: ClientId” pair is guaranteed to be unique in mesh.
3) Stand alone (Use “ROUTING=OFF” during compilation, also default mode)
A stand alone device is any OIC device in the current form. i.e. it won't look out for resources or make there resources available across hops.
Between an OIC server and client, there can be number of Gateway's, hence Gateway's need to interact with each other and form routing tables so that they can take intelligent routing decisions, hence:
A Gateway device executes following steps:
1) Host virtual resource “oic/gateway”, generate unique ID.
2) Search for resource “oic/gateway” over all active transports.
>> For ex: “GW 1” sends “GET” over both IP subnets and BT.
3) Immediate neighbor gateways responds for the GET request and inform their presence to neighbors. Response payload contains Gateway representation with unique ID and its routing table.
>> For ex: “GW 2” and “GW 3” responds to request by “GW 1”. While only “GW 1” responds to requests by “GW 2” and “GW 3”.
4) On receiving response, each gateway sends OBSERVE request to neighbor gateways. This is done to enable routing table update notifications between neighbors.
>> For ex: “GW2” starts observing “GW1” while “GW1” starts observing “GW2” and “GW3”.
5) At this point, every gateway will have routing table entry for neighbor gateway’s with hop count as 1.
>> For ex: “GW 1” will have entry for “GW2” and “GW3” as 1 hope. “GW3” will have entry for “GW1” as 1 hope.
6) Gateway’s then propagate info about their neighbor’s across hops.
>> For ex: “GW1” sends notification to “GW3” that “GW2” is available via it at 1 hope, “GW3” then adds new routing table entry for "GW2" via "GW1" with 2 hops.
7) An entry for “End device” is made only when a multicast or uni-cast packet is received from it.
8) Unlike Gateway’s, “End device” detection does not generate any routing traffic as the addition is kept local to the border gateway that detected the device.
9) This is done to help minimize routing table size at Gateway’s and the routing traffic.
10) To achieve routing data to End devices, a “GatewayID:ClientId” pair is added as source or destination. By this mechanism, intermediate Gateways refer only to the “GatewayID” prefix to determine next hop address and border gateway uses “ClientId” suffix to route it to appropriate end device.
11) Removal of neighbor gateway can be detected in max 45 seconds (configurable) and results in mesh re-configuring itself to find new paths.
12) Similarly, any addition of new gateway will be detected and notified to neighbors to reconfigure in case optimal path is available.
a.EndDevice (A) sends multicast GET request with an empty “RM” option. (Empty “RM” option is added to request Gateway devices to look out for resource across hops).
b.At Gateway (A):
1> CA receives the multicast packet (as its listening to all multicast in the network) and notifies RI. 2> RI checks with RM whether it needs to process packet. RM replies in positive since the received packet is a multicast, hence all nodes in mesh needs to process it. 3> RM generates new clientID for EndDevice (A) (reused on subsequent requests / responses from same client), adds source = <Gateway(A)ID:Client(A)ID> in "RM" CoAP option in the received packet and sends modified packet as multicast to all transports except the one for incoming packet.
c.At Gateway (B):
1> Since source is available in "RM" option, Gateway (B) will not generate ClientID for EndDevice (A) and will only forward the packet same way as done by Gateway (A). Note: Routing protocol uses mCastSeqNo to avoid loops between Gateway's. More on that in code.
d.At EndDevice (B):
1> CA receives multicast packet and notifies RI. 2> RI put source information from "RM" header option into "routeData" member in OCDevAddr with the help of RM utility function (RMUpdateInfo). 3> RI then processes packet and either responds itself (for oic/res) or a response is triggered by application with the same OCDevAddr as passed in step 2. 4> In either case before calling CASendResponse(), RI calls RM utility function (RMAddInfo) to add "RM" header option in packet with destination = <Gateway(A)ID:Client(A)ID> from OCDevAddr. The updated response packet is then sent to Gateway (B).
e.Back at Gateway (B):
1> CA receives the unicast packet and notifies RI. 2> RI checks with RM whether it needs to process packet. RM replies in negative since the received packet is having different destination. 3> RM generates new clientID for EndDevice (B) (reused on subsequent requests / responses from same client), adds source = <Gateway(B)ID:Client(B)ID> in "RM" CoAP option in the received packet. 4> RM checks routing table for next hop address for "Gateway(A)ID" and forwards modified packet as unicast to Gateway (A).
f.Back at Gateway (A):
1> CA receives the unicast packet and notifies RI. 2> RI checks with RM whether it needs to process packet. RM replies in negative since the received packet is for an associated client. 3> RM checks routing table to get address for Client(A)ID, and forwards the packet.
g.Back at EndDevice (A):
1> CA receives unicast packet and notifies RI. 2> RI put source information from "RM" header option into "routeData" member in OCDevAddr with the help of RM utility function (RMUpdateInfo). 3> RI then processes packet and might choose to send a unicast request with OCDevAddr as passed in step 2. 4> Before calling CASendRequest(), RI calls RM utility function (RMAddInfo) to add "RM" header option in packet with destination = <Gateway(B)ID:Client(B)ID> from OCDevAddr. The updated request packet is then sent to Gateway (A).
“RM” header option is always removed before passing any packet to RI layer at both Endpoint and Gateway's.
Summary of changes in RI
1) Stack mode is set to OC_CLIENT_SERVER in Gateway devices irrespective of the mode set by application.
2) A virtual resource “oic/gateway” is hosted in Gateway devices.
3) When ROUTING=GW, on receiving a request or response from CA, RI will first check with RM whether it needs to handle packet or it has to be forwarded to other gateway / endpoint.