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.
Summary of changes in RI
1) When ROUTING=GW, the stack mode is set to OC_CLIENT_SERVER irrespective of the mode set by the application.
2) A virtual resource OC_RSRVD_GATEWAY_URI[“oic/gateway”] is defined when ROUTING=GW is enabled.
3) OC_GATEWAY is added to the enum “OCVirtualResources” for virtual resource handling when a request is received.
4) 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.