One document matched: draft-behringer-anima-autonomic-addressing-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>

<rfc ipr="trust200902" docName="draft-behringer-anima-autonomic-addressing-01" category="std"  >

<front>
<title abbrev="Autonomic Addressing">An Autonomic IPv6 Addressing Scheme</title>

<author fullname="Michael H. Behringer" initials="M.H." surname="Behringer">
  <organization>Cisco Systems</organization>
  <address>
    <postal>
      <street>Building D, 45 Allee des Ormes</street>
      <city>Mougins</city>
      <region/>
      <code>06250</code>
      <country>France</country>
    </postal>
    <email>mbehring@cisco.com</email>
  </address>
 </author>

<date day="18" month="June" year="2015" />

<area>Operations and Management</area>
<workgroup>ANIMA</workgroup>

<abstract>
	<t>This document describes a generic IPv6 addressing scheme which is suitable for autonomic nodes, where node addressing must not depend on a centrally managed scheme. It assumes a unique domain name and device name, and automatically derives a unique IPv6 address from those. The scheme allows for a flat address hierarchy as well as optionally, when required, the definition of zones which are aggregatable. 
	</t>
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">
	<t>
	In an Autonomic Network, as defined in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>, and specified in more detail in <xref target="I-D.behringer-anima-reference-model"/>, one of the design goals is to minimise central functions. Address management traditionally is a centralised function, where addresses are assigned to nodes. In this document we assume that each node has already been assigned with a unique node name, and a domain name. We introduce an addressing scheme and an algorithm that allows the calculation of a unique IPv6 ULA address inside a domain. In other words, once a device has a unique node and domain name, this addressing scheme and algorithm allows for distributed self-management of addressing inside a network.</t>

	<t>The addressing scheme described here is specifically designed for both the data plane of a network, as well as the Autonomic Control Plane (ACP; see <xref target="I-D.behringer-autonomic-control-plane"/>). It is for communication inside the domain only, specifically to support self-management functions.</t>

</section> 
<!-- intro -->

<section anchor="requirements" title="Requirements and Assumptions">
	<t>An autonomic addressing scheme has the following requirements: 
	<list style="symbols">
		<t>Zero-touch for simple networks: Simple networks should have complete self-management of addressing, and not require any central address management, tools, or address planning. </t>
		<t>Low-touch for complex networks: If complex networks require operator input for autonomic address management, it should be limited to high level guidance only, expressed in Intent.</t>
		<t>Flexibility: The addressing scheme must be flexible enough for nodes to be able to move around, for the network to grow, split and merge. </t>
		<t>Robustness: It should be as hard as possible for an administrator to negatively affect addressing (and thus connectivity) in the autonomic context. </t>
		<t>Support for virtualization: Autonomic Nodes may support Autonomic Service Agents in different virtual machines or containers. The addressing scheme should support this architecture. </t>
		<t>Simplicity: To make engineering simpler, and to give the human administrator an easy way to trouble-shoot autonomic functions. </t>
		<t>Scale: The proposed scheme should work in any network of any size. </t> 
		<t>Upgradability: The scheme must be able to support different addressing concepts in the future. </t>
	</list>
	</t>
	
	<t>We assume that each node has a unique domain name and a unique node name inside that domain, for example "node17.domain.com". </t>	
</section>
<!-- requirements --> 

<section anchor="fundamentals" title="Fundamental Concepts of Autonomic Addressing">
    <t>IPv6 only: Autonomic processes should use exclusively IPv6, for simplicity reasons.</t>
	<t>Usage: Autonomic addresses are exclusively used for self-management functions inside a trusted domain. They are not used for user traffic. Communications with entities outside the trusted domain use another address space, for example normally managed routable address space.</t>
	<t>Separation: Autonomic address space is used separately from user address space and other address realms. This supports the robustness requirement.</t>
	<t>Loopback-only: Only loopback interfaces of autonomic nodes carry a routable address; all other interfaces exclusively use IPv6 link local for autonomic functions. The usage of IPv6 link local addressing is discussed in <xref target="RFC7404"/>.</t> 
	<t>Use-ULA: For loopback interfaces of autonomic nodes, we use Unique Local Addresses (ULA), as specified in <xref target="RFC4193"/>. An alternative scheme was discussed, using assigned ULA addressing. The consensus was to use standard ULA, because it was deemed to be sufficient. </t>
	<t>No external connectivity: They do not provide access to the Internet. If a node requires further reaching connectivity, it should use another, traditionally managed address scheme in parallel. </t>
</section>
<!-- fundamentals -->

<section anchor="scheme" title="The Base Addressing Scheme">
	<t>The Base ULA addressing scheme for autonomic nodes has the following format:</t>
	<t><figure title="Base Addressing Scheme" anchor='base-addr-scheme'>
   	<artwork>
  8      40          3                     77        	           
+--+--------------+------+------------------------------------------+
|FD| hash(domain) | Type |             (sub-scheme)                 |
+--+--------------+------+------------------------------------------+
	</artwork>
	</figure></t>
	<t>The first 48 bits follow the ULA scheme, as defined in <xref target="RFC4193"/>, to which a type field is added: 
	<list style="symbols">
		<t>"FD" identifies a locally defined ULA address. </t>
		<t>The "global ID" is set here to be a hash of the domain name, which results in a pseudo-random 40 bit value. It is calculated as the first 40 bits of the MD5 hash of the domain name, in the example "domain.com".</t>
		<t>Type: Set to 000 (3 zero bits). This field allows different address sub-schemes in the future. The goal is to start with a minimal number of sub-scheme initially, but to allow for extensions later if and when required. This addresses the "upgradability" requirement. Assignment of types for this field should be maintained by IANA.</t>
	</list></t>
</section>
<!-- scheme -->

<section anchor="sub-schemes" title="Possible Sub-Schemes">
	<t>The sub-schemes listed here are not intended to be all supported initially, but are listed for discussion. The final document should define ideally only a single sub-scheme for now, and leave the other "types" for later assignment. </t>

	<section anchor="scheme-1" title="Sub-Scheme 1">
		<t><figure title="Addressing Scheme 1" anchor='addr-scheme-1'>
		<artwork>
          51                 13                    64	           
+------------------------+---------+--------------------------------+
|    (base scheme)       | Zone ID |         Device ID              |
+------------------------+---------+--------------------------------+
		</artwork>
		</figure></t>
		<t>The fields are defined as follows: [Editor's note: The lengths of the fields is for discussion.]
		<list style="symbols">
			<t>Zone ID: If set to all zero bits: Flat addressing scheme. Any other value indicates a zone. See section <xref target="hierarchy"/> on how this field is used in detail. </t>
			<t>Device ID: A unique value for each device. </t> 
		</list>
		</t> 
		<t>The device ID is derived as follows: In an Autonomic Network, a registrar is enrolling new devices. As part of the enrolment process the registrar assigns a number to the device, which is unique for this registrar, but not necessarily unique in the domain. The 64 bit device ID is then composed as: 
		<list style="symbols"> 
			<t>48 bit: Registrar ID, a number unique inside the domain that identifies the registrar which assigned the name to the device. A MAC address of the registrar can be used for this purpose. </t>
			<t>16 bit: Device ID, a number which is unique for a given registrar, to identify the device. This can be a sequentially assigned number. </t> 
		</list>
		</t>
		<t>The "device ID" itself is unique in a domain (i.e., the Zone-ID is not required for uniqueness). Therefore, a device can be addressed either as part of a flat hierarchy (zone ID = 0), or with an aggregation scheme (any other zone ID). A address with zone-ID could be interpreted as an identifier, with another zone-ID as a locator.</t>
	</section> 
	<!-- scheme-1 -->

	<section anchor="scheme-2" title="Sub-Scheme 2">
		<t><figure title="Addressing Scheme 2" anchor='addr-scheme-2'>
		<artwork>
          51                 13                    64-V           ?
+------------------------+---------+----------------------------+---+
|    (base scheme)       | Zone ID |         Device ID          | V |
+------------------------+---------+----------------------------+---+
		</artwork>
		</figure></t>
		<t>The fields are defined as follows: [Editor's note: The lengths of the fields is for discussion.]
		<list style="symbols">
			<t>Zone ID: As in sub-scheme 1. </t>
			<t>Device ID: As in sub-scheme 1.</t>
			<t>V: Virtualization bit(s): 1 or more bits that indicate a virtual context on an autonomic node.</t>
		</list>
		</t> 
		<t>In addition the scheme 1 (<xref target="scheme-1"/>), this scheme allows the direct addressing of specific virtual containers / VMs on an autonomic node. An increasing number of hardware platforms have a distributed architecture, with a base OS for the node itself, and the support for hardware blades with potentially different OSs. The VMs on the blades could be considered as separate autonomic nodes, in which case it would make sense to be able to address them directly. Autonomic Service Agents (ASAs) could be instantiated in either the base OS, or one of the VMs on a blade. This addressing scheme allows for the easy separation of the hardware context.</t>
		<t>The location of the V bit(s) at the end of the address allows to announce a single prefix for each autonomic node, while having separate virtual contexts addressable directly.</t>
	</section> 
	<!-- scheme-2 -->

</section> 
<!-- sub-schemes -->

<section anchor="hierarchy" title="Address Hierarchy">
<t>The "zone ID" allows for the definition of a simple address hierarchy. If set to zero, the address scheme is flat. In this case, the addresses primarily act as identifiers for the nodes. Used like this, aggregation is not possible. </t>
<t>If aggregation is required, the 13 bit value allows for up to 8191 zones. (Theoretically, the 13 bits for the zone ID would allow also for two levels of zones, introducing a sub-hierarchy. We do not think this is required at this point, but a new type could be used in the future to support such a scheme.)</t>
<t>Another way to introduce hierarchy is to use sub-domains in the naming scheme. The node names "node17.subdomainA.domain.com" and "node4.subdomainB.domain.com" would automatically lead to different ULA prefixes, which can be used to introduce a routing hierarchy in the network, assuming that the subdomains are aligned with routing areas. </t> 
</section> <!-- hierarchy -->

<section anchor="iana" title="IANA Considerations">
<t>The type field in the base addressing scheme should be maintained by IANA. </t>
</section> <!-- iana -->

<section anchor="security" title="Security Considerations">
<t>tbc</t>
</section> <!-- security -->

<section anchor="ack" title="Acknowledgements">
<t>The following people have been involved in developing this scheme: Toerless Eckert, Steinthor Bjarnason, BL Balaji, Ravi Kumar Vadapalli.</t>
</section> <!-- ack -->

</middle>

<back>

<references title="References">
<?rfc include='reference.RFC.4193'?>
<?rfc include='reference.RFC.7404'?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.behringer-anima-reference-model.xml"?>
<?rfc include="reference.I-D.behringer-autonomic-control-plane.xml"?>
</references>

</back>
</rfc>