User Tools

Site Tools


proposal_for_routing_manager_through_the_heterogeneous_network_transports

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
proposal_for_routing_manager_through_the_heterogeneous_network_transports [2015/05/21 13:40]
Abhishek Sharma
proposal_for_routing_manager_through_the_heterogeneous_network_transports [2015/06/15 14:04] (current)
Abhishek Sharma
Line 10: Line 10:
 In the current IoTivitiy design, an OIC client can discover and communicate with any resource hosted by OIC server in the same network. For Ex: OIC Client can detect light resource on an OIC server when both are in the same IP/BT/BLE network. ​ In the current IoTivitiy design, an OIC client can discover and communicate with any resource hosted by OIC server in the same network. For Ex: OIC Client can detect light resource on an OIC server when both are in the same IP/BT/BLE network. ​
  
-In the new proposal, if any Intermediary gateway device has multiple transports for ex: IP and BT networks it can bypass ​the request and responses so that resources on different network can be discovered and communicated. This allows OIC clients to communicate with resource even though they are not in the same transport. +In the new proposal, if any Intermediary gateway device has multiple transports for ex: IP and BT networks it can forward ​the request and responses so that resources on different network can be discovered and communicated. This allows OIC clients to communicate with resource even though they are not in the same transport. 
-For ex: An OIC client who is on IP network can discover a resource available on BT network if any intermediary gateway node having IP and BT network can bypass ​the messages.+For ex: An OIC client who is on IP network can discover a resource available on BT network if any intermediary gateway node having IP and BT network can forward ​the messages.
  
-In the initial proposal, we want to make use of the existing COAP header ​options ​to intimate about the request generator and response generator without having much complex of routing mechanisms.\\+In the initial proposal, we want to make use of the existing COAP header ​option ​to intimate about the request generator and response generator without having much complex of routing mechanisms.\\
  
 {{:​routing_manager_single_hop.png?​200|}}\\ {{:​routing_manager_single_hop.png?​200|}}\\
-**We propose to add necessary options in CoAP packets itself, such as "​src_addr"​ and "​dest_addr"​.**+ 
 +**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: **128** 
 + 
 +Option Data Format: **Binary** 
 + 
 +^  1 byte   ​^ ​ '​len_src'​ bytes  ^  1 byte    ^  '​len_dest'​ bytes     ​^ ​ 2 bytes    ^ 
 +|  len_src ​ |  source_address ​  ​| ​ len_dest ​ |  destination_address ​ |  hop_Count ​ |
  
 Find below a complete sequence of steps for Find resource and Unicast request. Find below a complete sequence of steps for Find resource and Unicast request.
  
 1) Find Resource (Multicast Request, Uni-cast Response) : 1) Find Resource (Multicast Request, Uni-cast Response) :
-     a.End device (A) sends multicast find resource.+     a.End device (A) sends multicast find resource ​with an empty "​MS"​ option. (Empty "​MS"​ option is added to 
 +       ​notify Gateway devices to forward the request across hops)
      ​b.Gateway receives the multicast packet (as its listening to all multicast in the nw).      ​b.Gateway receives the multicast packet (as its listening to all multicast in the nw).
-     ​c.Gateway adds the src_addr ​option in the received packet and sends modified packet as multicast to all                  +     ​c.Gateway adds source address = address of End Device A in "​MS"​ CoAP option in the received packet and sends 
-       transports except the one used for incoming packet. ​+       modified packet as multicast to all transports except the one for incoming packet. ​
      d.End device (B) receives the multicast packet on appropriate adapter and passes it to CA.      d.End device (B) receives the multicast packet on appropriate adapter and passes it to CA.
-     e.CA layer parses the 'src_addr' option and updates the RemoteEndPoint struct with dest_addr = src_addr ​ +     e.CA layer parses the 'MS' ​CoAP option ​to get source address ​and updates the RemoteEndPoint struct with 
-       which is address of original sender ​ (End Device A).  +       dest_addr = src_addrwhich is address of original sender (End Device A). (Now RemoteEndPoint has 2 
-        ​(Now RemoteEndPoint has 2 addresses, one is gateway address, another is actual destination address ​   +       addresses, one is gateway address, another is actual destination address (dest_addr).
-        ​(dest_addr).+
      f.RI Layer, sends the response using CASendResponse() API with same RemoteEndPoint as it was passed in       f.RI Layer, sends the response using CASendResponse() API with same RemoteEndPoint as it was passed in 
        step '​e'​ along with response info.        step '​e'​ along with response info.
-     g.CA Layer, makes the CoAP packet with adding ​dest_addr ​option from the RemoteEndPoint and sends it to  +     g.CA Layer, makes the CoAP packet with adding ​"​MS"​ CoAP option ​with destination address ​from the 
-       Gateway. +       RemoteEndPoint and sends it to Gateway. 
-     ​h.Upon receiving the uni-cast response, Gateway device ​reads the dest_addr ​and realizes that packet is  +     ​h.Upon receiving the uni-cast response, Gateway device ​parse "​MS"​ option to get destination address ​and 
-       not destined for itself. +       realizes that packet is not destined for itself. 
-     ​i.Gateway devices ​removes the dest_addr from incoming packet, ​adds the src_addr ​= address of End  +     ​i.Gateway devices adds the source address ​= address of End Device B; and sends the packet to End Device A.
-       Device B; and sends the packet to End Device A.+
  
 2) Unicast Request : 2) Unicast Request :
Line 44: Line 53:
      ​b.Gateway receives the unicast packet and realizes that packet is not destined for itself ​      ​b.Gateway receives the unicast packet and realizes that packet is not destined for itself ​
       (dest_addr != GW addr).       (dest_addr != GW addr).
-     ​c.Gateway adds the src_addr ​option in the received packet and sends modified packet as a +     ​c.Gateway adds the source address to "​MS" ​option in the received packet and sends modified packet as a 
        ​unicast to End Device (B).         ​unicast to End Device (B). 
      d.End device (B) receives the unicast packet on appropriate adapter and passes it to CA.      d.End device (B) receives the unicast packet on appropriate adapter and passes it to CA.
-     e.CA layer parses the '​src_addr' ​option and updates the RemoteEndPoint struct with  +     e.CA layer parses the "​MS" ​option and updates the RemoteEndPoint struct with dest_addr = src_addr which  
-     dest_addr = src_addr which is address of original sender ​ (End Device A).  +       is address of original sender ​ (End Device A).  
-      (Now RemoteEndPoint has 2 addresses, one is gateway address, another is actual destination address (dest_addr).+       ​(Now RemoteEndPoint has 2 addresses, one is gateway address, another is actual destination address 
 +       (dest_addr).
      f.RI Layer, sends the response using CASendResponse() API with same RemoteEndPoint as it was passed in step       f.RI Layer, sends the response using CASendResponse() API with same RemoteEndPoint as it was passed in step 
        '​e'​ along with response info.        '​e'​ along with response info.
-     g.CA Layer, makes the CoAP packet with adding ​dest_addr ​option from the RemoteEndPoint and +     g.CA Layer, makes the CoAP packet with adding ​destination address to "​MS" ​option from the RemoteEndPoint and 
        sends it to Gateway.        sends it to Gateway.
-     ​h.Upon receiving the uni-cast response, Gateway device reads the dest_addr ​and realizes that +     ​h.Upon receiving the uni-cast response, Gateway device reads the destination address ​and realizes that 
        ​packet is not destined for itself.        ​packet is not destined for itself.
-     ​i.Gateway devices ​removes the dest_addr from incoming packet, ​adds the src_addr = address of End Device B;  +     ​i.Gateway devices adds the src_addr = address of End Device B; and sends the packet to End Device A.
-       and sends the packet to End Device A.+
  
 ==== Phase 2) Routing Manager - Multi Hop  ==== ==== Phase 2) Routing Manager - Multi Hop  ====
proposal_for_routing_manager_through_the_heterogeneous_network_transports.txt · Last modified: 2015/06/15 14:04 by Abhishek Sharma