%%%
    title           = "Spinel Host-Controller Protocol"
    abbrev          = "Spinel Protocol (Unified)"
    category        = "info"
    docName         = "draft-rquattle-spinel-unified-@SOURCE_VERSION@"
    ipr             = "noDerivativesTrust200902"
    keyword         = ["Spinel", "IPv6", "NCP"]
    date            = @SOURCE_DATE@
    submissionType  = "independent"
    
    [pi]
    editing         = "yes"
    compact         = "yes"
    subcompact      = "yes"
    comments        = "yes"
    
    [[author]]
    initials        = "R."
    surname         = "Quattlebaum"
    fullname        = "Robert S. Quattlebaum"
    organization    = "Nest Labs, Inc."
    
        [author.address]
        email       = "rquattle@nestlabs.com"
        
        [author.address.postal]
        street      = "3400 Hillview Ave."
        city        = "Palo Alto"
        region      = "California"
        code        = "94304"
        country     = "USA"
    
    [[author]]
    role            = "editor"
    initials        = "J.H."
    surname         = "Woodyatt"
    fullname        = "James Woodyatt"
    organization    = "Nest Labs, Inc."
    
        [author.address]
        email       = "jhw@nestlabs.com"
        
        [author.address.postal]
        street      = "3400 Hillview Ave."
        city        = "Palo Alto"
        region      = "California"
        code        = "94304"
        country     = "USA"
%%%

.# Abstract

This document describes the Spinel protocol, which facilitates the control and
management of IPv6 network interfaces on devices where general purpose
application processors offload network functions at their interfaces to network
co-processors (NCP) connected by simple communication links like serial data
channels. While initially developed to support Thread(R), Spinel's layered
design allows it to be easily adapted to other similar network technologies.

This document also describes various Spinel specializations, including support
for the Thread(R) low-power mesh network technology.


{mainmatter}

# Introduction #

Spinel is a host-controller protocol designed to enable interoperation over simple serial connections between general purpose device operating systems (OS) and network co-processors (NCP) for the purpose of controlling and managing their IPv6 network interfaces, achieving the following goals:

*   Adopt a layered approach to the protocol design, allowing future
    support for other network protocols.
*   Minimize the number of required commands/methods by providing a
    rich, property-based API.
*   Support NCPs capable of being connected to more than one network
    at a time.
*   Gracefully handle the addition of new features and capabilities
    without necessarily breaking backward compatibility.
*   Be as minimal and light-weight as possible without unnecessarily
    sacrificing flexibility.

On top of this core framework, we define the properties and commands
to enable various features and network protocols.

## About this Draft ##

This document is currently in a draft status and is changing often.
This section discusses some ideas for changes to the protocol that
haven't yet been fully specified, as well as some of the impetus for
the current design.

### Scope ###

The eventual intent is to have two documents: A Spinel basis document
which discusses the network-technology-agnostic mechanisms and a
Thread(R) specialization document which describes all of the Thread(R)-specific
implementation details. Currently, this document covers both.

### Renumbering ###

Efforts are currently maintained to try to prevent overtly
backward-incompatible changes to the existing protocol, but if you are
implementing Spinel in your own products you should expect there to be
at least one large renumbering event and major version number change
before the standard is considered "baked". All changes will be clearly
marked and documented to make such a transition as easy as possible.

To allow conclusive detection of protocol (in)compatibility between
the host and the NCP, the following commands and properties are
already considered to be "baked" and will not change:

*   Command IDs zero through eight. (Reset, No-op, and Property-Value
    Commands)
*   Property IDs zero through two. (Last status, Protocol Version, and
    NCP Version)

Renumbering would be undertaken in order to better organize the
allocation of property IDs and capability IDs. One of the initial
goals of this protocol was for it to be possible for a host or NCP to
only implement properties with values less than 127 and for the NCP to
still be usable---relegating all larger property values for extra
features or other capabilities that aren't strictly necessary. This
would allow simple implementations to avoid the need to implement
support for PUIs ((#packed-unsigned-integer)).

As time has gone by and the protocol has become more fleshed out, it
has become clear that some of the initial allocations were inadequate
and should be revisited if we want to try to achieve the original
goal.


{{spinel-frame-format.md}}

{{spinel-data-packing.md}}

{{spinel-commands.md}}

{{spinel-prop.md}}

{{spinel-status-codes.md}}

{{spinel-tech-thread.md}}

{{spinel-feature-network-save.md}}

{{spinel-feature-host-buffer-offload.md}}

{{spinel-feature-jam-detect.md}}

{{spinel-feature-gpio.md}}

{{spinel-feature-trng.md}}

{{spinel-security-considerations.md}}

{backmatter}

{{spinel-framing.md}}

{{spinel-test-vectors.md}}

{{spinel-example-sessions.md}}

{{spinel-basis-glossary.md}}

# Acknowledgments #

Thread is a registered trademark of The Thread Group, Inc.

Special thanks to Nick Banks, Jonathan Hui, Abtin Keshavarzian, Yakun Xu,
Piotr Szkotak, Arjuna Sivasithambaresan and Martin Turon for their
substantial contributions and feedback related to this document.

This document was prepared using [mmark](https://github.com/miekg/mmark)
by (Miek Gieben) and [xml2rfc (version 2)](http://xml2rfc.ietf.org/).