https://deevnet.github.io/deevnet-docs/docs/architecture/edge-devices/Recent content in Edge Devices on Deevnet IoTaaSHugoen-ushttps://deevnet.github.io/deevnet-docs/docs/architecture/edge-devices/access/Mon, 01 Jan 0001 00:00:00 +0000https://deevnet.github.io/deevnet-docs/docs/architecture/edge-devices/access/<h1 id="how-an-edge-device-reaches-its-application"> How an Edge Device Reaches Its Application <a class="anchor" href="#how-an-edge-device-reaches-its-application">#</a> </h1> <p>A device is attached to an access segment. The application it belongs to runs in a tenant overlay that nothing outside can reach. This page is how the two meet.</p> <hr> <h2 id="the-shape-of-the-problem"> The shape of the problem <a class="anchor" href="#the-shape-of-the-problem">#</a> </h2> <p>Two facts define the whole answer, and neither is negotiable:</p> <ul> <li><strong>A tenant has no inbound path.</strong> The fabric provides egress only; nothing outside a tenant can open a connection into it ( <a href="https://deevnet.github.io/deevnet-docs/deevnet-docs/docs/architecture/decisions/0003-tenant-egress-single-member-fabric/">ADR-0003</a>).</li> <li><strong>A device has no route to tenant space.</strong> Its segment&rsquo;s policy permits device-facing platform services, and nothing else. Adding a path from the IoT segment into the tenant overlay would give <em>every</em> device reach into <em>every</em> tenant, which is exactly the isolation the model exists to provide.</li> </ul> <p>So neither side can dial the other. They meet at a <strong>rendezvous service</strong> on the substrate that both sides dial <em>out</em> to.</p>