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/08/31 15:43]
Abhishek Sharma
routing_through_heterogeneous_transports [2016/04/28 11:01] (current)
Abhishek Sharma
Line 16: Line 16:
 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: **20**+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 ​ |  multicast_seq_no ​ |+|  message_type  ​|  len_src ​ |  source_address ​  ​| ​ len_dest ​ |  destination_address ​ |  multicast_seq_no ​ |
  
 ---- ----
  
-In the proposal, OIC devices are classified into categories:​\\+In the proposal, OIC devices are classified into categories:​\\
  
 1) **Gateway** (Use "​ROUTING=GW"​ during compilation)\\ 1) **Gateway** (Use "​ROUTING=GW"​ during compilation)\\
Line 31: Line 33:
  
 2) **End device** (Use "​ROUTING=EP"​ during compilation)\\ 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.  +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 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+
  
 {{ :​multi-hop-scenario.png?​500 |}} {{ :​multi-hop-scenario.png?​500 |}}
Line 63: Line 62:
 ==== Architecture ==== ==== Architecture ====
 {{ :​routing_manager_architecture.png?​600 |}} {{ :​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**\\ **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.\\ +1) Stack mode is set to OC_CLIENT_SERVER ​in Gateway devices ​irrespective of the mode set by application.\\ 
-2) A virtual resource ​OC_RSRVD_GATEWAY_URI["​oic/​gateway"​is defined when ROUTING=GW is enabled.\\ +2) A virtual resource "​oic/​gateway"​ is hosted in Gateway devices.\\ 
-3) OC_GATEWAY is added to the enum "​OCVirtualResources"​ for virtual resource handling when a request is received.\\ +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. ​ 
-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. ​+
  
 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.1441035782.txt.gz · Last modified: 2015/08/31 15:43 by Abhishek Sharma