An NVRAM index in a TPM is a nonvolatile entity. There is a certain amount of nonvolatile space in a TPM that a user can configure for storage. When configured, it's given an index and a set of attributes, chosen by the user.
NVRAM indexes aren't considered objects by the TPM specification, because they have more attributes than a standard object. Reading and writing them can be individually controlled. They can be configured as entities that look like PCRs, counters, or bit fields. They can be made into “write once” entities as well. Chapter 11 explains their properties and use cases.
NVRAM indexes have both an associated authorization value and an authorization policy. The authorization value can be changed at the will of the owner of the index, but the policy can't be changed once it's set at the creation of the NVRAM index. NVRAM indexes are associated with a hierarchy when they're created. Hence, when the hierarchy is cleared, the NVRAM indexes associated with that hierarchy are deleted.
Objects are similar to NVRAM in that they belong to a hierarchy and have data and authorization mechanisms, but they have fewer attributes.
A TPM object is either a key or data. It has a public part and perhaps a private part such as an asymmetric private key, a symmetric key, or encrypted data. Objects belong to a hierarchy. All objects have both associated authorization data and an authorization policy. As with NV indexes, an object's policy can't be changed after it's created.
When an object is used in a command, some commands are considered administrative and others are considered user commands. At object creation, the user decides which of these commands can be performed with the authorization data and which can exclusively be done with a policy. This comes with a caveat: certain commands can only be done with a policy no matter how the attributes are set at key creation.
Like NVRAM indexes, all objects belong to one of the four hierarchies: platform, storage, endorsement, or NULL. When a hierarchy is cleared, all objects belonging to that hierarchy are also cleared.
Typically, most objects are keys. They're described in detail in the Chapter 10.
Using keys or other objects requires the use of a TPM non-persistent entity: the session.
A nonpersistent entity never persists through power cycles.  Although a nonpersistent entity can be saved (see TPM2_ContextSave), a TPM cryptographic mechanism prevents the saved context from being loaded after a power cycle, thus enforcing volatility.
This type of entity has several classes.
Authorization sessions, including HMAC and policy sessions, are perhaps the most widely used, permitting entity authorization, command and response parameter encryption, and command audit. Chapter 13 is devoted to their use.
Hash and HMAC event sequence entities hold the intermediate results of the typical crypto library “start, update, complete” design pattern. They permit the hashing or HMAC of data blocks that are larger than the TPM command buffer. Chapter 9 describes their application.
In contrast to a nonpersistent entity, a persistent entity persists through power cycles.
-  To be precise, it doesn't persist through what the specification refers to as a TPM Reset (a reboot). It does persist through a TPM Restart (resume from hibernate) or TPM Resume (resume from sleep).