The following figure illustrates how a new device joins an autonomic network.

Figure 2. New Device Joining the Autonomic Network

1. The new device sends out a hello message to the neighbor. In this case, the neighbor is part of an autonomic network domain.
2. The hello message includes the unique device identifier (UDI) of the new device.
3. The autonomic device acts as a proxy and allows the new device to join this autonomic network domain. The autonomic network device advertises itself with the domain information to its Layer 3 neighbors.
4. On receiving the autonomic network hello message from the neighbor and detecting the UDI information, the new device is validated with the autonomic registrar.
5. The new device advertises its domain certificate in its hello message with all neighbors. The neighbor information is exchanged every 10 seconds.

Note	If the neighbor information changes, the entry is deleted and neighbor discovery is restarted. In the absence of a domain certificate and devices working with UDI, UDI is exchanged at a 10-second interval.

There is a need to allow network wide policies in certain autonomic deployments. Channel Discovery on active autonomic devices probe VLAN IDs on all interfaces. However, the possible VLAN ID range used across layer 2 clouds is significantly smaller than the 4095 possible VLAN IDs. Channel discovery probes are sent every 10 seconds, so probing all VLAN IDs can potentially take a long time. Limiting the VLAN ID range for channel discovery can decrease the bootstrap time for new devices.

The configuration of the VLAN ID range is done in a network wide fashion. The VLAN ID is configured on one device and the configuration is flooded through the entire network automatically. This is achieved using the Intent Distribution Protocol, which works as follows:

• Every autonomic device sends IDP messages with the current timestamp, the last time that intent has been ingested, to its neighbors. This floods the timestamp on the entire domain.
• A user ingests an intent at any ‘allowed’ place in the network.
• This increases the intent version number on that device, while it also locally interprets the intent.
• Neighbors notice the revision in the timestamp and pull in the newest revision of the intent from the neighbor that indicates the newer version number.
• This updates the intent in the network, and all nodes execute the intent locally.

The key features of autonomic networking intent is as follows:

• Unambiguous configuration—An unambiguous representation of the intent is provided by the network. The autonomic intent command is converted and stored as an XML file in the flash. Thus, it is easy to parse and is unambiguous as each XML tag is unique.
• Persistency and reload—The intent is persistent across reloads. The intent configuration is not nvgen'ed on any device. The persistency is ensured via the XML file in flash, which will be parsed when autonomic is enabled after a reload, whether via manual autonomic configuration or via autonomic configuration in the startup configuration. After the intent file is parsed, channel discovery probes going out remain in the intent range, but, incoming channel discovery probes could be outside the intent range. This establishes a temporary channel discovery channel and an autonomic control plane with a neighboring device having the latest version of intent. After the new device receives a new intent from the neighboring device, the temporary channel becomes stale and is deleted so that a new channel is created conforming to the new intent range.
• Intent Security—The intent is created only on the registrar. The registrar adds the certificate and signs the contents before distributing the intent. Any changes in the intent configuration results in resigning the intent. The receiving devices use the public certificate received along with intent to verify the signature. On verification, the devices copy the intent and, if required, redistribute the new intent to its neighbors. Signature verification will fail if intent is modified.
• Default Intent—When the intent is removed from the registrar by using the no form of the command, a default intent will be generated and propagated. The default intent is just like a new intent but contains the keyword “default” in the outer vlans tag in the XML file.
• Multiple Registrars—There could be multiple registrars in the network, for redundancy purposes. Because all devices are in the same domain they must have the same intent version. Intent distribution protocol allows intent to be injected at any registrar and also propagate the intent to all neighbors in the given domain. This ensures that the latest intent version is maintained across all devices.

The place in the network to ingest that network wide configuration (or Autonomic Intent) is limited to the registrars. Use the autonomic intent command to configure intent followed by the acp outer-vlans command.

This configuration is not saved in the NVRAM because the intent pertains to network wide configuration and is, hence, stored ‘in the network.’ If any device, including the registrar, forgets about the intent, the IDP ensures that the device receives a copy of the intent immediately.

You cannot configure the intent on nonregistrar autonomic devices. However, on receiving the XML intent file, the nonregistrar autonomic devices parse the file and store the VLAN ID values.

When autonomic is disabled, the intent file is deleted from flash. If the intent file is deleted from flash, you must wait until the neighboring devices pushes the latest intent (which might happen when the autonomic control plane is and reestablished later) or when the neighboring devices receive a newer intent.

When the outer VLAN range is configured on the registar, an intent XML file, an_intent_cp.xml, is created in the flash. If theXML file exists, it is deleted and a new file is created. A version number, which is the version number, is populated in the XML file with the domain ID.

In case of nonregistrar devices, a file with the name, an_intent_cp.xm, is created in flash to store the received intent. This ensures that a device, after a reboot, can execute the intent immediately, when autonomic is enabled. This file should not be deleted.

The following is a sample of the XML file:

<autonomic intent>
<acp>
<outer vlans>
30,35,50-60,25,80
</outer vlans>
</acp>
</autonomic intent>
</autonomic domain cisco.com>
<ANR signature>
SAFKJNKG3242107FEGEGEF3234
</ANR signature>
<ANR public cert>
NHSKLFF901IF112E13R3938RY093
FREIFJFIGIO3FOIHF03F3JFNII3FJG
RGFRGFNKRNGR4R980-921D23-R
JFDPOIEJF02IGFR3209RU309UF3IF
3KG3GF03IGF3-IF3KGFK3[P[KGF3
</ANR public cert>

The following is a high level overview of how intent works for a new device and an existing device:

• New Device—When the autonomic control plane of a new device is up, IDP message is triggered from a neighbor device. The neighbor device fetches the version number from the XML file and send a message to the new device. Sometimes, a neighbor might request for intent (via another IDP message) if its version number is lower or if does not havea version at all. In such cased, the sending device parses the contents of XML file and constructs an IDP message whose payload includes the XML file, the signature, and the public certificate. This IDP message is unicast over the ACP of the device whose ACP just came up.
• Existing Device—A device recieves a new intent when the device has no intent or the existing intent version number, on the device, is lower than the recieved intent. When a device, having the XML file exists on the device recieves a new intent, the device verifies the signature of the intent and overwrites the existing intent, along with new signature and new certificate. After the intent is applied, all existing channel discovery channels are verified for stale channels. Stale channels are channels with outer encapsulationthat fall outside the range of the new intent. Stale channels are removed to create new channels based on new intent. The outgoing channel discovery probes must be sent for VLANs only in the range specified by the intent.

Note	Irrespective of intent availabilty, all incoming channel discovery packets are allowed whether they fall in the intent VLAN range. This is to ensure that there is no deadlock when a new intent is propogated in the network.