User Tools

Site Tools


routing_through_heterogeneous_transports

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
routing_through_heterogeneous_transports [2015/06/17 08:44]
Ashok Babu Channa [Phase 2) Routing Manager - Multi Hop]
routing_through_heterogeneous_transports [2016/04/28 11:01] (current)
Abhishek Sharma
Line 1: Line 1:
-===========Routing ​Manager through the heterogeneous network transports=========== +===========Routing ​Through Heterogeneous Connectivity=========== 
-This proposal is to have a seamless communication between IoTivity devices over Heterogeneous ​transports. The requirement is to send IoTivity messages between client and server even though they are not directly connected ​or on the same transport.+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.
  
-We are proposing to handle the requirements in two phases.\\ +----
-In the first phase, client and server which are reachable via single hop are handled.\\ +
-In the second phase, client and server which are at multi hop distance are handled. +
-  +
-==== Phase 1) Routing Manager ​Single Hop ( Message Switching )  ====+
  
-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 ​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 ​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. +In the new proposal, if any Intermediary gateway device has multiple ​connectivity ​for ex: IP and BTit 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 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 proposalwe 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.\\+For ex: An OIC client on IP network can discover a resource available on BTif any intermediary gateway node having IP and BT can forward ​the messages.
  
-{{:​routing_manager_single_hop.png?​200|}}\\+{{ :​routing_manager_single_hop.png?​400 |}}
  
-**To achieve the functionality,​ we propose to add a new CoAP option with details as follows:**+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 Number: **65524 (Experimental,​ needs expert review before using vendor-specific option number)**
  
-Option ​Max Data Length: **128**+Option ​Minimum ​Data Length: **1** 
 + 
 +Option Maximum Data Length: **20**
  
 Option Data Format: **Binary** Option Data Format: **Binary**
  
-^  1 byte   ​^ ​ '​len_src'​ bytes  ^  1 byte    ^  '​len_dest'​ bytes     ​^ ​ 2 bytes    ^ +^  1 byte   ^  1 byte   ​^ ​ '​len_src'​ bytes  ^  1 byte    ^  '​len_dest'​ bytes     ​^ ​ 2 bytes    ^ 
-|  len_src ​ |  source_address ​  ​| ​ len_dest ​ |  destination_address ​ |  ​hop_Count ​ |+|  message_type  ​|  len_src ​ |  source_address ​  ​| ​ len_dest ​ |  destination_address ​ |  ​multicast_seq_no ​ |
  
-Find below a complete sequence of steps for Find resource and Unicast request.+----
  
-1) Find Resource (Multicast RequestUni-cast Response) : +In the proposalOIC devices ​are classified into categories:​\\
-     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). +
-     ​c.Gateway adds source address = address of End Device A in "​MS"​ CoAP option in the received packet and sends +
-       ​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. +
-     e.CA layer parses the '​MS'​ CoAP option to get source address and updates the RemoteEndPoint struct with +
-       ​dest_addr = src_addr, which is address of original sender (End Device A). (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 '​e'​ along with response info. +
-     g.CA Layer, makes the CoAP packet with adding "​MS"​ CoAP option with destination address from the +
-       ​RemoteEndPoint and sends it to Gateway. +
-     ​h.Upon receiving the uni-cast response, Gateway device parse "​MS"​ option to get destination address and +
-       ​realizes that packet is not destined for itself. +
-     ​i.Gateway devices adds the source address = address of End Device B; and sends the packet to End Device A.+
  
-2Unicast Request : +1**Gateway** (Use "​ROUTING=GW" ​during compilation)\\ 
-     a.End device (A) sends unicast request with dest_addr = address of End Device B (address found using Above  +A gateway ​will generally have multiple connectivity and will act as intermediaryresponsible for forwarding ​CoAP packets between different connectivity. Gateway’s are given unique ID’s for easy identification ​and trackingThis ID acts similar to prefixes in IPv6. A gateway can also optionally host or look out for any regular OIC resource across hops.
-       Find Resource Procedure). +
-     b.Gateway ​receives the unicast packet and realizes that packet is not destined for itself  +
-      ​(dest_addr != GW addr). +
-     ​c.Gateway adds the source address to "MS" option in the received packet and sends modified packet as a  +
-       ​unicast to End Device (B) +
-     d.End device (B) receives the unicast packet on appropriate adapter and passes it to CA. +
-     e.CA layer parses the "​MS"​ option and updates the RemoteEndPoint struct with dest_addr = src_addr which  +
-       is address of original sender ​ (End Device ​A).  +
-       (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  +
-       '​e'​ along with response info. +
-     g.CA Layermakes the CoAP packet with adding destination address to "​MS"​ option from the RemoteEndPoint and  +
-       sends it to Gateway. +
-     ​h.Upon receiving the uni-cast response, ​Gateway ​device reads the destination address ​and realizes that  +
-       ​packet is not destined for itself. +
-     i.Gateway devices adds the src_addr = address of End Device B; and sends the packet to End Device ​A.+
  
-==== Phase 2) Routing Manager - Multi Hop  ===+2) **End device** (Use "​ROUTING=EP" during compilation)\\ 
-{{ :multi-hop-scenario.png?200 |}}+An end device will not forward CoAP packets across different connectivity,​ but can look out for resources or make their 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 will not be notified to Gateway’s across mesh. End devices are given ID’s by border Gateway’s which will be unique among respective Gateway'​s end devices and not in entire mesh. However a “Gateway IDClientId” pair is guaranteed to be unique in mesh
  
-**Gateway executes following steps**:+{{ :multi-hop-scenario.png?​500 |}}
  
-1) Create “oic/​gateway” resource.+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:
  
-2) Search for “oic/​gateway” ​resource ​over all active transports. ​+**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.    >>​ For ex: “GW 1” sends “GET” over both IP subnets and BT.
-3) Immediate neighbor gateways responds for the GET request and inform ​there presence to neighbors. +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” +   >>​ 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”. 
-      ​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. 
-4) On receiving response, each gateway sends OBSERVE request to neighbor gateways.+   >>​ 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. 
 +---- 
 + 
 +==== Architecture ==== 
 +{{ :​routing_manager_architecture.png?​600 |}} 
 +\\ 
 +Find below a complete sequence of steps for Multicast and Uni-cast packets.\\ 
 +**Setup:** EndDevice (A, Client) -> Gateway (A, Router) -> Gateway (B, Router) -> EndDevice (B, Server)\\ 
 + 
 +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
  
-5) On detecting a new end device, a gateway updates its routing table and send notification to neighbor gateways notifying that a device is available via it. 
-   >>​ For ex: On detecting “ED 2”,  “GW 2” sends a notification to “GW 1” which updates its routing table. 
-6) Gateway then forwards this information to other neighbor gateways. 
-   >>​ For ex: “GW 1” then notifies “GW 3” that “Ed 2” is reachable via me with 2 hopes. 
-7) Gateways can be configured to send periodic “confirmable requests” to check on the availability of neighbor nodes. On detection of a non-responsive node, the information gets propagated same way as done for “addition of new node”. 
  
 History:​[[proposal_for_routing_manager_through_the_heterogeneous_network_transports|Proposal for Routing Manager through the heterogeneous network transports]] History:​[[proposal_for_routing_manager_through_the_heterogeneous_network_transports|Proposal for Routing Manager through the heterogeneous network transports]]
routing_through_heterogeneous_transports.1434530682.txt.gz · Last modified: 2015/06/17 08:44 by Ashok Babu Channa