<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.6.4 (Ruby 2.6.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-richardson-snac-building-use-case-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.12.4 -->
  <front>
    <title abbrev="building-gateway">Inter-Gateway Discovery and Communications in Building Automation Systems</title>
    <seriesInfo name="Internet-Draft" value="draft-richardson-snac-building-use-case-00"/>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="W." surname="Pan" fullname="Wei Pan">
      <organization>Huawei Technologies</organization>
      <address>
        <email>william.panwei@huawei.com</email>
      </address>
    </author>
    <date year="2022" month="June" day="26"/>
    <area>Internet</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes a use case where gateways need to discover each other in order to maintain building safety systems</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>XXX - Intra-Gateway or Inter-Gateway?</t>
      <t>This document describes a scenario where gateway to gateway discovery is needed in order to maintain a series of building safety systems.</t>
      <t>New Buildings are being built with digitally controlled automation, and existing buildings are being retrofitted with new automation systems.
While some buildings can and do leverage legacy wiring systems such as BACnet, and able to deploy technology like <xref target="RFC8163"/> to turn existing twisted pair control systems into IPv6 networks, other buildings are using various combinations of 802.15.4, Powerline ethernet, etc.  as an alternative to explicit wiring.</t>
      <t>Whether wired or wireless passing of a signal through re-inforced concrete floors presents a challenge, particularly in the retrofit situation.</t>
      <section anchor="building-network-topology">
        <name>Building Network Topology</name>
        <t>The sheer height of many buildings means that even per-floor gateways may be more than 100m away (copper ethernet distance) from the control room.
The distance issue then requires that fiber be used to connect the building, or that sub-control rooms be established at regular intervals.</t>
        <t>As an alternative to this resulting star topology, with many critical points, a daisy-chain topology can be established, where the gateways on adjacent floors (or areas) are directly connected.
To provide redundancy an additional cable can connect alternating floors, ideally via a different conduit.
A routing protocol such as <xref target="RFC6550"/> can be used, or a metro-ethernet topology can be used to connect the gateways.</t>
        <t>This deals with the Layer 1 and Layer 2 resiliency in face of destruction of the control room, or the conduits leading to the control room.
But what about the resiliency at layer 4 and at the application layer?
Regulations often say that when a smoke detector is tripped in one area that some or all adjacent areas need also to signal for occupants to leave.
Emergency doors and stairwells need to be unlocked, emergency lighting and communications systems activated.</t>
      </section>
      <section anchor="scope-of-problem">
        <name>Scope of problem</name>
        <t>Many industrial settings can assume a competent operator to plan and manage the network.
On the other hand, the HOMENET problem description assumes that there is no such operator <xref target="RFC7368"/>.</t>
        <t>In the building case there is a hybrid situation.
For most of the regular, boring operation of the building there is a central point of control, a
human operator is reachable, and maintenance people or processes can be deployed.</t>
        <t>It is during an emergency that the problems arise.
The central point of control and the humans involved may become unavailable due to network partition, or because there are other things occupying their attention.</t>
        <t>This document presents the problem of having (network) adjacent gateways being able discover each other and interoperate with each other's sensor network from a just powered on situation.
The criteria of just powered on does not imply a factory default situation.
This criteria is to acknowledge that the power situation might be unstable: batteries and backup generators might not come on immediately, but there could be some short duration when power is unstable.
As a result, any kind of configuration or network convergence that depends upon connectivity that would exist during regular operation can not be assumed.</t>
        <t>A key point about the just powered-on situation is that it assumes that any mesh network (whether <xref target="RFC6550"/> or Metro-Ring) may not have formed yet, and may never form.</t>
        <t>A network forming with <xref target="RFC6550"/> would normally do address assignment from the PIOs contained in the DODAGs.
For stability, resiliency, and ease of deployment, the Gateway devices would likely number their sensors using either a ULA locally generated, or via an IPv6 prefix allocated via DHCPv6-PD using an extremely long (essentially infinite) lifetime.</t>
        <t>The Gateways could advertise their prefixes into a <xref target="RFC6550"/> mesh using DAO messages.
(On a network built using a metro-ring protocol, then the entire gateway network is a single L2 domain, and a single OSPF area could be created)</t>
        <t>Note that <xref target="RFC6550"/> includes support for non-Grounded DODAGs (no DODAG root) which would permit adjacent nodes to communicate and form a DAG, it is unclear yet if that mechanism can be used for this.</t>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>To be considered.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Something about building networks and physical security.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>None.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>Hello.</t>
    </section>
    <section anchor="changelog">
      <name>Changelog</name>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="BCP14" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6550">
          <front>
            <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
            <author fullname="T. Winter" initials="T." role="editor" surname="Winter">
              <organization/>
            </author>
            <author fullname="P. Thubert" initials="P." role="editor" surname="Thubert">
              <organization/>
            </author>
            <author fullname="A. Brandt" initials="A." surname="Brandt">
              <organization/>
            </author>
            <author fullname="J. Hui" initials="J." surname="Hui">
              <organization/>
            </author>
            <author fullname="R. Kelsey" initials="R." surname="Kelsey">
              <organization/>
            </author>
            <author fullname="P. Levis" initials="P." surname="Levis">
              <organization/>
            </author>
            <author fullname="K. Pister" initials="K." surname="Pister">
              <organization/>
            </author>
            <author fullname="R. Struik" initials="R." surname="Struik">
              <organization/>
            </author>
            <author fullname="JP. Vasseur" initials="JP." surname="Vasseur">
              <organization/>
            </author>
            <author fullname="R. Alexander" initials="R." surname="Alexander">
              <organization/>
            </author>
            <date month="March" year="2012"/>
            <abstract>
              <t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6550"/>
          <seriesInfo name="DOI" value="10.17487/RFC6550"/>
        </reference>
        <reference anchor="RFC8163" target="https://www.rfc-editor.org/info/rfc8163">
          <front>
            <title>Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks</title>
            <author fullname="K. Lynn" initials="K." role="editor" surname="Lynn">
              <organization/>
            </author>
            <author fullname="J. Martocci" initials="J." surname="Martocci">
              <organization/>
            </author>
            <author fullname="C. Neilson" initials="C." surname="Neilson">
              <organization/>
            </author>
            <author fullname="S. Donaldson" initials="S." surname="Donaldson">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks.  This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8163"/>
          <seriesInfo name="DOI" value="10.17487/RFC8163"/>
        </reference>
        <reference anchor="RFC7368" target="https://www.rfc-editor.org/info/rfc7368">
          <front>
            <title>IPv6 Home Networking Architecture Principles</title>
            <author fullname="T. Chown" initials="T." role="editor" surname="Chown">
              <organization/>
            </author>
            <author fullname="J. Arkko" initials="J." surname="Arkko">
              <organization/>
            </author>
            <author fullname="A. Brandt" initials="A." surname="Brandt">
              <organization/>
            </author>
            <author fullname="O. Troan" initials="O." surname="Troan">
              <organization/>
            </author>
            <author fullname="J. Weil" initials="J." surname="Weil">
              <organization/>
            </author>
            <date month="October" year="2014"/>
            <abstract>
              <t>This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing.  The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements.  The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking.  The architecture describes the need for specific protocol extensions for certain additional functionality.  It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network.  There are no recommendations in this text for the IPv4 part of the network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7368"/>
          <seriesInfo name="DOI" value="10.17487/RFC7368"/>
        </reference>
        <reference anchor="diehard">
          <front>
            <title>Die Hard</title>
            <author initials="J." surname="McTiernan">
              <organization/>
            </author>
            <author initials="J." surname="McTiernan" fullname="John McTiernan">
              <organization/>
            </author>
            <author>
              <organization>Twentieth Century Fox</organization>
            </author>
            <date year="1988"/>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAMwEuWIAA31YXW/buBJ9168g0Ieb4NpG0m27Wb/sukk/smiaoMlF+7ag
pbHFjUTqkpQdY9H/vmeGlGy33S3QQpbI4Xycc2bY6XRaRBMbmqtrG8lP3+lI
W71TVyaUbkN+p7St1KVr296aUkfjbFDGqte9aSpj12rRR9fKe3W/C5HaUOjl
0tNmrpZ5zXSdjBaVK61ucVbl9SpOvSlr7avg7DRYXU7H9X2gaanxz9lZUYQI
D/7QjbPYGH1Phem8PIX4/Ozsl7PnhfakcwCWYvG43f+YXvFRBTyfqxCroujM
XOHPM1Vqq3CQ0t4j3hOzUrpp1I7CqXJe1TrUqiZPhVLRlXP+gMfgfPS0CnMx
UdFK900MWDF837XpM/8sdB9r5+dFMUXK8PJmpj6NMWN1SsYNv6Lm+JPz67m6
R+TUtHD03q3iFmGqz84/8kHUatPMVVv6/xqKq9/CsHRW6uG4zzN1p/fnfCaT
f4vx973e4s0DlbV1jVsbOrC7NU1jdDvrtMWi32pZOytdWxTWea73huZY/vry
7vzFXH16e3lx/vOLojB2dfgZ71+9fHmWHy/OX/2UH3/+6dUFP1aGOGZ+RJ4T
EK8Mqfd4Ke+GFPKzynH9PlM35YNBfSUa+ZBC/N3V9vtvEu7DlmxEqmp1iYce
wH7rnmRFBXTO1fkvFxco1HSq9DJEr8tYFA+1CQqg7VtsQbVD6c2SgtICHEao
2jJGVAZ4UJaoYjRUmT6KdFkrF7GKWeN8hQd8R5ZtxN+RIyroFcUdAJQ4JJ60
pqoaKopnDGfvqr5knhXFly9fEBa/0yNhgdkjBv/6b+6Hkqz2xh27z44Nj9XI
f5OiQlw/DADGyAM7yq3+KZhZUXyk7SgZcABnLokX8o4ItKEslVmbCAruVOk4
2qbBkXpUl4kIET2ZEIeN3xrzhG0rEyM2ikmLU/cW9u58rk1D4HJLB3ZYD/iI
yqmGELleEx7WutzBmJeo0n4VetRUB/V6cQmFSY7pJSxy4alrHDI5sGqnGvNI
6q+/Mv6/fuVVwJ/dxxK3eIDPnTZ+CH48DGl26vpu8wrRxC2zf5LxdJyCPrCp
DVe1RzCuXRqb5RqVuTh7Pjt/OXsxUXduS74xlhSxFQmAYjlTHBGnoGHhFAaz
p/TUNaY0MecApfxcy0Z+AZ9demgoBPgfxAmcB1SYtdWNirV3/bpGbaaiDSX2
IMQStSK1apzz2OcpAKEMTCgg6m7XNIE1H03ZN9oDEgAaDh0rDOuxl+jg0LNn
+270MeVIPbhOss8kQKVrgsM1mXUd2TvI5O4gfS1pZCnWOioU3qoOLBLX9rxu
QYklqdYh01ho1fnZWas0M+WkdF3HTM/pZOqgZZV0qlbeteL3UFTvXDsTl4ZF
oFfo2SbO9fT/HrnMrqzAVc+HQmtEU2DEUhnF4OD8hAsgy0O/nB4eE3gr4ZBl
YxA/EBpxwJrzyZgiv9ENM3Pxo6pHVg54guYmwI+aSZ9SOknckhxCUFAjlLlz
sAlkaqipCbsp6sgly1uEW8fuTLL0cDBjlsFRXf2pS5arjI0TxMftHV2ZUV4h
P2VMGsHJoArpdECQ25iK8VH1tkJedxJUVRnGCPwrhZ/sxpDFMWLEl86aKJgQ
AdoYzZGY1QouwhfsqXoTZ8UCqe1lC07EWMA8zWIgDOdmB4bncLlwUiANiKEw
0xEi3ybmRyUesjIbhBy+hZR7/vxB7wCPcxGf9PycK2YaQxw+sr9CIhntEH4M
S9I6+Oe3eMwQoiHKANXTQiYBwrfgfd1DCxhweolUZFaOx+J9I868SKqYFuiO
RSSJsHz+tfgkUBz0KQL9gRsQG94yFyAgrYNwVtCJMsJDZCB6A6alPmRJYJGx
z0rOecYANwJIUJMaMhLnOJqsSZAh5cqyx3CTZjcEvKFZ8aYlv5YwKsEeRwDE
Gr+lptn3dq6XbVz5yNWlcU/D6sJp423l8cA8iDmmCrPRglqWrXtIh5QIaAI+
MVzdMKsM6oCSGbgaKMZ9d4JUIFDN1jvkBUFiv9ecHvjVNbmDgZrcvDjzuWfM
itskoKlzQMDgOv9+f3vz5uObh8GBPCR0Uql0XFajKGzlWcAlyI8nC/B5nvv6
FVFd2yN9SkPSuFmrerf0pjrU77ew0boQB2xmkZqopZOumw46AO9o+8AsV9wP
OsQLM2ihSEXd8wQ9+ivKhqmMFWGS88WCaEWOO3JdI2BCSkp0NQoDSVNrl9pd
RzZT9T7V+wAFQ7KGjHJzNoGS6P+Tl+IFbxJXuedvXLOhKredkuHdW73BaC46
VvWi0rm4qVOmGclxxyh1PyadRTMVHZrOQBLg73L6MG/oyEBKnfR4YBzb8kE4
7HStN7z9JB9/uqfcKORpHku+/mAS5nClB6WiUFK1/YL/gDFkcdcaQ5ROqtWf
4AWyhwmGRw97CCPJL9oRhlHNXn67tHLE4EXh2g4Sr1keAYfdcIk7toU8jMaM
aIQuH63bYiYVZg1FZvv7nRjYecIQgZBWh3vFkhMsAzJHvYSZvlPASkJjyFvY
MSkzjJi2pcogLQ167bIfuFe6vqnYtqhdwK0oMgLTwaKZyRu4O5w+k+6eGzlj
faceIS4ZeSuzHrYfZBofNgnMOU7AnmwFo50bu6fZmDiotbgls+xAiGHM2DOX
GcQhwvukKkyihXqkXebCvpkc1m16WGKpA5+I8e9Imjgs/KjHEE62eUQ97MkI
8Uaa8Ce4eCrMYo8AZuKGAJdwZ4+DIOAj3wHki7g6AhEvOEZB7KH9lAe5HPMI
gVsExg/PYzFPxWsrlBoHwrvr2yDsh/SkjsZvr26vFu9CkkSuILpqBAb2/TVf
glhTpbGzILHhJObDVbCijYF0ZZf4/gGHbN8uRQWY9IldIV8ayCRWqv99WCg0
NgkgQzRPMDIR2XQPgS6szBM3Wyzlewt/vHp/iW/Tu6tsk0XxKXoII2w1jvWC
xRRKI9ZxFzAW/DqFe7gqmpZmaVR/N0hIgruuUIVokpwZn8+mfC3SRxUQDKTT
rxa3/DOgDSKdJ7c8TwwVTFfO7GUezPzhSDdJ0zhnlP09uB8PJqTlsAHo24fn
qDV3kHwPHN7f3t+9TSPKSFxcejhfp7gOu5jZdRiAsWXTowOjwXYd05sHFevs
9B2mTss38AQQSK9LjzyTxVOw30A6U7nBuZYZMmiydWxRZsthJCHxlJEMd2Fl
wpQS2SgxCXnmgTKr5F+Li6y2JrRHo+pKRkbDs2nxTN15DDXofZcYdTBCJ86H
ggfzpYyP8jYNPeqeSqhE/H71PWRNelQWg7HND/de8bqrd0FuHCHbEaPXi4+L
7wx+xJAoXxd76Way4NN7DHROvl0iujVhFi/Sf7mwQBfF33hwjogXFQAA

-->

</rfc>
