diff --git a/crypto_design.dox b/crypto_design.dox
new file mode 100644
index 0000000..ffe0df4
--- /dev/null
+++ b/crypto_design.dox
@@ -0,0 +1,556 @@
+/* Copyright (c) 2043, Linaro Limited
+ * All rights reserved
+ *
+ * SPDX-License-Identifier:     BSD-3-Clause
+ */
+
+/**
+@page crypto_design ODP Design - Crypto API
+For the implimentation of the ODP crypto API please see @ref odp_crypto.h
+
+@tableofcontents
+
+@section revision_history Revision History
+Revision | Issue Data | Description | Author
+---------|------------|-------------|--------
+0.1      | 4/9/2014   | Introduction started, Basic Functions | Bill, Alexandru
+0.2      | 4/15/2014  | Completed intro, added TOC, started use cases, miscellaneous formatting, API comments | Bill
+0.3      | 4/22/2014  | Added Use Case section to include results of design discussions held during ODP team calls | Bill
+0.4      | 4/30/2014  | Design review from ODP crypto sprint--action to resolve | Bill
+0.5      | 5/5/2014   | Rewrite incorporating review comments--ready for final review | Bill
+1.0      | 5/30/2014  | Final version for LNG-SC approval | Bill
+
+@section introduction Introduction
+This document describes the ODP Crypto API. 
+Cryptography is an important part of data plane processing as many communication protocols make use of cryptographic functions. 
+Moreover, many SoCs incorporate cryptographic hardware that can significantly accelerate these operations compared to their software equivalents as well as provide validated hardware functional correctness and security boundaries necessary for system-level security certifications such as FIPS-140 Level 2 and above. 
+@section requirements Requirements
+@subsection use_of_terms Use of Terms
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119).
+@subsection uses_of_cryptography Uses of Cryptography
+Crypto functions cover a range of uses and capabilities designed to support data security, integrity, authentication, and non-repudiation.
+@subsubsection data_security Data Security
+Cryptography supports data security by making use of complex mathematical transformations that are not feasibly reversible without possession of the secret key used to encrypt message data. 
+@subsubsection data_integrity Data Integrity
+Cryptography supports data integrity through the use of cryptographic checksums (also known as secure hashes) that ensure the recipient that message data has not been altered either accidentally or maliciously while in transit.
+@subsubsection data_authentication Data Authentication
+Cryptography supports data authentication through the uses of Message Authentication Codes (MACs) that enable the recipient to verify that a message was sent from an authorized counterparty, and hence was not forged.
+@subsubsection data_non_repudiation Data Non-Repudiation
+Cryptography supports data non-repudiation through the use of digital signatures that enable a recipient or third party to verify the identity of the sending party and prevents the sending party from later denying that they originated a signed message. 
+@subsection scope Scope
+ODP crypto support is designed to provide a portable framework for accessing SoC-specific cryptographic functions of most use to the data plane. 
+This is predominantly symmetric crypto operations used to support the encryption and decryption of data at line rate using hardware acceleration and offload. 
+Specifically excluded in this support are public key operations and other crypto functions mainly used in the control plane. 
+@subsection cryptographic_operations_in_the_data_plane Cryptographic Operations in the Data Plane
+ODP crypto APIs cover the following areas:
+@subsubsection ciphering Ciphering
+Ciphering refers to mathematical transformations that use a secret key to encipher data, transforming the original data (referred to as plaintext) into ciphertext, thereby making it unintelligible to anyone not in possession of the key. 
+Similarly, ciphering is also used to decipher data, allowing someone in possession of the correct key to transform received ciphertext back into plaintext. 
+Approved block ciphers are listed [here](http://csrc.nist.gov/groups/ST/toolkit/block_ciphers.html) and SHOULD be supported by each ODP implementation.
+@subsubsection hasing Hashing
+A hash is a cryptographic digest of a message that can be used to represent it for comparison or integrity checking. 
+Hash functions are designed so that any alteration of a message will alter the hash and that it is computationally infeasible to craft a message that generates the same hash value as another message. 
+Secure hash functions approved for cryptographic use are listed by NIST [here](http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html) and SHOULD be supported by each ODP implementation.
+@subsubsection zeroization Zeroization
+To preserve the security of data, certain transient data held in data buffers MUST be cleared to zeros upon buffer free.
+Such capability is referred to as zeroization. 
+ODP supports zeroization as a buffer pool attribute.
+@subsubsection random_number_generation Random Number Generation
+Because cryptography relies heavily on “unguessable” keys of various sorts, random number generation (RNG) is an integral part of cryptographic processing. 
+Random numbers are used in key generation, initialization vectors (IVs), various types of padding bytes, and various other uses collectively referred to as nonces, that serve to “harden” cryptographic processing.
+
+There are two types of random number support of interest. 
+Hardware random data, also known as entropy, that is the result of inherently random physical processes, and deterministic random bit generation (DRBG) that is used in certain certified cryptographic operations. 
+Approved DRBG algorithms are listed in [NIST SP 800-90A](http://en.wikipedia.org/wiki/NIST_SP_800-90A) and ODP does not specify which algorithms are available on a given implementation. 
+As such ODP implementations MAY use any approved DRGB algorithm but SHOULD support at least one of them. 
+Additionally, ODP implementations MUST NOT represent non-approved algorithms as DRBG implementations. 
+Validated algorithms are listed in the [NIST DRBG Validation List](http://csrc.nist.gov/groups/STM/cavp/documents/drbg/drbgval.html).
+
+@subsubsection capability_inquiry Capability Inquiry
+To enable applications to adapt to the implementation models offered across different SoC platforms, ODP provides APIs to allow applications to inquire about underlying crypto capabilities. 
+A given ODP implementation may offer crypto as hardware features, software features, or not available on a given platform.
+@subsection cryptographic_algorithms Cryptographic Algorithms and Protocols
+A cryptographic algorithm is a mathematical transform that provides one of the cryptographic operations described above. 
+They in turn are used as building blocks in creating cryptographic protocols. 
+These are complete sets of rules for how to exchange data securely using cryptography. 
+Both cryptographic algorithm and protocol design are highly specialized disciplines that involve high levels of public scrutiny and validation. 
+As a result, applications simply make use of approved cryptographic algorithms and protocols.
+@subsection cryptographic_operations Cryptographic Operations
+Cryptographic operations may be initiated by software or directly by hardware as part of the RX or TX packet path processing. 
+For ODP software-initiated cryptographic operations are the primary use case. 
+ODP provides APIs for performing data ciphering, hashing, random number generation, and capability inquiry.
+@subsection performance_expectations Performance Expectations
+In the data plane, the total processing budget for a packet may only be a few hundred cycles, so function invocation overhead MUST be kept to a minimum. 
+This has several implications.
+
+-# When work is dispatched to a thread, all information needed by the thread to process the work request SHOULD be immediately at hand. 
+Ideally any context or variables needed for the operation have been pre-warmed in the cache to avoid the latency hits associated with cache misses. 
+SoCs having hardware schedulers generally do this pre-staging of data to minimize such latencies, and ODP implementations are expected to exploit such platform capabilities whenever possible.\n\n
+
+-# Calls to ODP functions SHOULD NOT involve excessive amounts of parameter passing and (depending on the implementation) SHOULD be inlined as much as possible to avoid call overhead. 
+One technique that has proven useful is to allow for parameters to be passed as an explicit thread-local static structure. 
+Such use of “templating” means that a single function can support a rich set of options but the caller can configure a template matched to specific use and only vary the one or two parameters that differ from call to call.\n\n
+
+-# Kernel traps or interrupts SHOULD NOT be part of any non-exception path function processing. 
+Kernel calls and such are acceptable only during one-time initialization logic or certain types of unusual error recovery operations. 
+Often the best way to handle the latter is to pass the work to a dedicated recovery thread (or back to the control plane) rather than attempting to handle the condition inline. 
+For example, a link-down condition will trigger various recovery actions that might best be handled in this manner.
+
+@subsection use_by_existing_code Use by Existing Code
+Most applications wishing to make use of ODP represent substantial existing investment that must be preserved. 
+Insofar as possible, ODP functions need to be orthogonal to existing application environments and structures to permit easy intermixing with pre-existing code.
+@subsection data_references Data References
+Packet data is inherently of variable length however it is often more efficient to organize memory into fixed-sized buffers that can be chained together on demand to contain packets. 
+The application SHOULD normally not need to be aware of such lower-level segmentation and should be able to treat a packet as a single object. 
+Alternately, especially when dealing with existing code, data segmentation MUST be explicitly specifiable via scatter/gather lists. 
+For example, data encryption or decryption may be invoked on a list of data segments as part of a single function call.
+@subsection chained_operations Chained Operations
+Crypto operations such as hashing and encryption, or decryption and verification, are very commonly used in combination. 
+For ODP, it is sufficient to support one cipher and one hash/authentication operation in a single call and this combination MUST be supported to avoid the call and dispatch overhead of separate invocations.
+
+@subsection key_management Key Management and Session Data
+Keying is an area of particular sensitivity in crypto processing since keys are highly confidential and may be subject to legal requirements for safeguarding within special hardware enclosures.
+
+A session is the security context used to represent an active set of crypto operations that need to be applied to a flow on a packet-by-packet basis. 
+Generally a session is established upon detection of a flow requiring crypto processing and retained for the life of that flow. 
+It has been noted that this can involve cooperative processing between the control and data planes so several requirements stem from this:
+
+-# Session creation MAY need to be handled in an asynchronous manner. 
+This is to allow these to be created in batches by thread(s) that specialize in this activity.\n\n
+
+-# Sessions MAY need to reference keying material indirectly via key handling modules.\n\n
+
+-# Session creation MAY be performed by non-ODP code and communicated to data plane routines that make use of ODP crypto functions that need to reference the session information. 
+
+ODP session APIs and data structures SHOULD be represented by abstract data types that encapsulate implementation details for both platform efficiency and to accommodate these needs.
+Use Cases
+For ODP the major use cases of interest involve cryptographic algorithm acceleration. 
+Cryptographic protocol acceleration is reserved for future ODP releases.
+Buffers and Data Blocks
+Cryptographic operations may be performed directly on data contained in ODP packet buffers, or it may be performed on “raw” data blocks operating entirely under application control. 
+Note that when using raw data blocks not managed by ODP, the application must perform any needed zeroization using either its own or ODP-supplied buffer zeroization functions. 
+ODP automatic support for zeroization is limited to ODP-managed buffers. 
+ODP buffers allocated from buffer pools designated for crypto use will also have whatever alignment and/or addressability attributes needed by the implementation to support crypto API calls.
+
+Note: Some implementations may have difficulty dealing with application buffer addresses, as these may be virtual addresses that are mapped discontiguously into physical memory. 
+For such implementations, memory SHOULD be allocated contiguously and MAY need to be “registered” to have proper addressability for crypto operations. 
+This area of the design will be updated based on experience in dealing with different crypto implementations that have such requirements.
+Synchronization
+ODP operations fall into one of three categories:
+
+-# Inline (Synchronous): Upon return from a call the operation is complete. 
+Operation is thus completely synchronous to the caller. 
+Inline is the appropriate model when the invoked function takes relatively few cycles or when the caller cannot feasibly progress without the results of the invoked function.\n\n
+
+-# Parallel: Upon return from a call the operation has been initiated, but is expected to complete shortly. 
+The caller continues to execute until it needs the result at which point it waits to complete the parallel operation. 
+The effect is as if the operation were inline except that the caller was able to execute in parallel with the operation for some application-determined period of time. 
+Parallel is the appropriate model when the operation being performed is relatively short (a few dozen up to perhaps 100 or 200 cycles) and the caller can usefully accomplish other processing on the same unit of work while the parallel operation is in progress, but not enough to justify the overhead of a formal queued work dispatch.\n\n
+
+-# Offloaded (Asynchronous): Upon return from the call the operation has been queued for execution. 
+A completion event will be queued back to the scheduler when the event is completed. 
+Offload is the appropriate model when the invoked function will take a substantial amount of cycles (thousands to tens of thousands) allowing the invoking thread/core to service other work until the operation completes. 
+For offloaded work, completion is indicated by a completion event being posted back to an application-designated completion queue. 
+Upon receipt the unit of work that initiated the offloaded operation continues processing with the results of the call.
+
+The synchronization models of interest are summarized in Figure 1:
+
+![Figure 1: Synchronization Models](./images/syncmodels.png)
+
+Note: Because few implementations are expected to offer the Parallel mode of  operation as described above, this mode is reserved for potential future use. 
+For ODP only synchronous and asynchronous crypto operations are defined.
+@section functional_definition Functional Definition
+@subsection abstract_data_types Abstract data types 
+The following enumerations define various algorithms used for ciphering and hashing. 
+These are the basic operations applied to input data. 
+
+A particular ODP implementation should map these values to the actual information to be passed to the crypto engine. 
+As such, the actual values of these enums is implementation-defined.
+
+Cipher algorithm encoding specifies the algorithm and cipher mode employed (as per security relevant RFCs - [4305](http://tools.ietf.org/html/rfc4305), [4868](http://tools.ietf.org/html/rfc4868), [4494](http://tools.ietf.org/html/rfc4494)).
+
+@code
+enum odp_cipher_alg {
+        ODP_CIPHER_ALG_NULL,
+        ODP_CIPHER_ALG_DES,
+        ODP_CIPHER_ALG_3DES_CBC,
+        ODP_CIPHER_ALG_AES_CBC,
+        ODP_CIPHER_ALG_AES_GCM,
+        ODP_CIPHER_ALG_AES_CTR,
+        ODP_CIPHER_ALG_KASUMI,
+        ODP_CIPHER_ALG_SNOW,
+        ...
+};
+@endcode
+
+Authorization algorithm encoding specifies the algorithm and the length of the authorization used (as per security relevant RFCs - [4305](http://tools.ietf.org/html/rfc4305), [4868](http://tools.ietf.org/html/rfc4868), [4494](http://tools.ietf.org/html/rfc4494)): 
+
+@code
+enum odp_auth_alg {
+        ODP_AUTH_ALG_NULL,
+        ODP_AUTH_MD5_96,
+        ODP_AUTH_ALG_SHA1_96,
+        ODP_AUTH_ALG_SHA1_160
+        ODP_AUTH_ALG_SHA2_256_128,
+        ODP_AUTH_ALG_SHA2_384_192,
+        ODP_AUTH_ALG_SHA2_512_256,
+        ODP_AUTH_ALG_AES_CMAC_96,
+        ODP_AUTH_ALG_AES_XCBC_MAC_96,
+        ODP_AUTH_ALG_SNOW,
+        ODP_AUTH_ALG_KASUMI,
+        ...
+};
+
+typedef union odp_crypto_alg_t {
+	enum odp_cipher_alg cipher;
+	enum odp_auth_alg auth;
+}odp_crypto_alg_t;
+@endcode
+@subsection parameter_structures Parameter Structures
+@subsubsection crypto_sessions Crypto Sessions
+The following structure describes a crypto session. 
+All packets / raw data buffers processed in a session share the data that defines the session. 
+A crypto session is defined by:
+
+- Operation type : encode or decode\n\n
+
+- Algorithms specifications, keys and , if required, initialization vectors. 
+When initialization vectors are not provided and they should be provided automatically by the crypto engine.\n\n
+
+- The operation mode: synchronous or asynchronous. 
+Synchronous operation blocks the caller until an operation status and result are available. 
+In synchronous mode there is at most only one outstanding crypto operation in the calling thread. 
+In asynchronous mode, the caller starts the crypto operation and later it may receive the status and the result together with a request context. 
+The operation status and result may also be received by a different thread.\n\n
+
+- Operation mode parameters: For asynchronous operation a completion event containing the status, the result and the request context is enqueued to a completion queue. 
+In case the queue is under the scheduler control, the scheduler determines who will receive the completion event and when. 
+When the completion queue is not scheduled, the thread which is supposed to get the operation output has to explicitly poll the completion queue. 
+
+Note that this is an abstract data type and its structure is implementation-specific. 
+The layout shown here is for illustrative purposes and the actual layout will vary from one implementation to the next to most closely align with the structures needed by the underlying SoC platform. 
+Applications set and reference fields in the session structure via accessor functions that hide the actual layout.
+
+@code
+typedef enum odp_crypto_op_t {
+        ODP_CRYPTO_OP_ENCODE,
+	ODP_CRYPTO_OP_DECODE
+}odp_crypto_op_t;
+
+typedef struct odp_key_t {
+}odp_key_t;
+ 
+typedef struct odp_crypto_session_t {
+	odp_crypto_op_t op;
+	struct {
+       	        enum odp_cipher_alg cipher_alg;
+       	        odp_key_t *key;
+       	        uint8_t *iv;
+       	        size_t iv_len;
+	} cipher;
+
+	struct {
+       	        enum odp_auth_alg auth_alg;
+       	        enum odp_auth_len auth_len;
+       	        odp_key_t *key;
+	} auth;
+
+	enum odp_crypto_op_mode {
+     	        ODP_CRYPTO_SYNC,
+                ODP_CRYPTO_ASYNC,
+	} op_mode;
+
+	struct {
+       	        uint32_t timeout;
+       	        struct {
+       	       	        odp_queue_t completion_queue;
+       	        } async;
+	} op_mode_params;
+
+	odp_session_proc_info_t session_proc_info;
+} odp_crxsypto_session_t;
+@endcode
+
+The completion queue contained in the session structure is an in/out parameter. 
+If provided, then the queue specified is associated with the session and is used to ensure order preservation on that session. 
+If not provided, one is created and returned to the caller. 
+Note that this completion queue is used to order operations performed on this crypto session. 
+It should not be confused with the completion queue specified on the odp_crypto_session_create() call (see below) that is used to control whether that call is itself processed in a synchronous vs. asynchronous manner.
+
+The following structure comprises processing information. 
+This is logically divided in two parts: 
+
+- Processing input info - When crypto engine provides support for protocol processing, this information is provided in a higher level common protocol terminology form and a particular implementation should be able to derive everything it needs from this definition. 
+In addition, for crypto engines able to automate tasks like memory allocation for the output a buffer pool id may be specified.\n\n
+
+- Processing output information - statistics about processed bytes/packets. 
+These are useful when a session expiration is based on traffic volume. 
+These statistics may be updated by the software or by the hardware crypto engine. 
+
+Again, this is an abstract type whose specific layout will vary based on implementation considerations. 
+Access to fields contained in the structure is only via accessor functions.
+
+@code
+typedef struct {
+        uint64_t pkts_processed;
+        uint64_t bytes_processed;
+        uint64_t pkts_errored;
+        uint64_t bytes_errored;
+
+        odp_buffer_pool_t out_pool;
+	
+} odp_session_proc_info_t;
+@endcode
+
+This enumeration defines which operations are applied and the order.
+
+@code
+enum odp_crypto_combination {	
+        ODP_CRYPTO_CIPHER_ONLY,
+        ODP_CRYPTO_AUTH_ONLY,
+        ODP_CRYPTO_AUTH_CIPHERTEXT
+};
+@endcode
+
+This structure defines a contiguous segment in the input data which starts at offset offset and is len bytes long.
+
+@code
+struct odp_data_range {
+        unsigned offset:16;
+        unsigned len:16;
+};
+@endcode
+
+@subsection api_functions API Functions
+
+@subsubsection Session Creation
+
+This function is used to create a crypto session. 
+The required parameters are:
+
+- Operation : encode/decode 
+- Processing info : cipher/auth/both
+- Preferred mode : sync or async. 
+- Algorithms suites, keys and optional IV
+
+Session creation can be synchronous or asynchronous. 
+Completion event argument is used to return the status and the session handle. 
+When completion queue is not provided (synchronous call), the completion event is available upon function call return. 
+When completion queue is provided (asynchronous call), the completion event is placed on the completion queue.
+
+@code
+typedef uint64_t odp_crypto_session_t;
+
+struct odp_session_params {
+        enum odp_crypto_operation op;
+        odp_session_proc_info_t proc_info;
+        enum odp_crypto_op_mode pref_mode;
+        enum odp_cipher_alg cipher_alg;
+        odp_key_t *cipher_key;
+        uint8_t *iv;
+        size_t iv_len;
+        enum odp_auth_alg auth_alg;
+        odp_key_t *auth_key;
+};
+
+enum odp_crypto_ses_create_err {
+        ODP_CRYPTO_SES_CREATE_NONE,
+        ODP_CRYPTO_SES_CREATE_ENOMEM,
+        /* Session creation error codes */
+};
+
+void
+odp_crypto_get_ses_create_compl_status(odp_buffer_t completion_event, enum  odp_crypto_ses_create_err *status);
+
+void
+odp_crypto_get_ses_create_compl_handle(odp_buffer_t completion_event, odp_crypto_session_t *handle);
+
+int odp_crypto_session_create(
+        struct odp_session_params *params,
+        odp_buffer_t completion_event,
+        odp_queue_t completion_queue);
+@endcode
+@subsection crypto_operation Crypto Operation
+
+Crypto operations are described by a parameter structure:
+@code
+struct odp_crypto_op_params {
+        odp_crypto_session_t session;
+        odp_packet_t pkt;
+        odp_packet_t out_pkt;
+        uint8_t *override_iv_ptr;
+        unsigned hash_result_offset;
+        struct odp_data_range cipher_range;
+        struct odp_data_range auth_range;
+};
+@endcode
+
+<table>
+<tr><th>Parameter</th><th>Meaning</th></tr> 
+<tr><td>session</td><td>Session to perform the operation</td></tr>
+<tr><td>pkt</td><td>Packet / buffer to be processed</td></tr>
+<tr><td>out_pkt</td><td>Handle of an output packet / buffer to be returned as the result of the operation. 
+There are three different ways this parameter is used, depending on the mode of operation requested by the caller and the capabilities of the underlying implementation:\n\n
+
+-# If out_pkt is the same as pkt this indicates that the operation should be performed in place.\n\n
+-# If out_pkt is different from pkt this indicates that output should be placed in the buffer supplied by the caller.\n\n
+-# If out_pkt is omitted (a null/invalid value supplied on input) this indicates that an output buffer should be allocated by the operation and returned as part of the completion event associated with the operation.\n\n
+
+Note that not every implementation will support all of these modes and MAY require that one mode be used in preference to others. 
+Any such implementation restrictions are communicated as output from session creation.</td></tr> 
+<tr><td>override_iv_ptr</td><td>Optional IV to use for this request</td></tr>
+<tr><td>hash_result_offset</td><td>Offset into the output packet where the hash result should be stored.</td></tr>
+<tr><td>cipher_range</td><td>The byte range (offset:length) of the data to be processed for ciphering.</td></tr>
+<tr><td>auth_range</td><td>The byte range (offset:length) of the data to be processed for authentication.</td></tr>
+</table>
+
+The crypto operation is initiated with a single call that passes the parameters for the operation and an event (for asynchronous completion).
+@code
+int odp_crypto_operation(
+        struct odp_crypto_op_params *params,
+        odp_buffer_t completion_event);
+@endcode
+
+Parameter | Meaning
+----------|--------
+params    | The parameter structure describing the crypto operation to be performed.
+completion_event | The event delivered on completion. 
+It provides information about the status of the operation, result and request context. 
+In synchronous mode the event is available upon function call return. 
+In asynchronous mode, the event is placed on the session / operation completion queue when the operation finished.
+
+Upon return the return code indicates whether the operation was synchronous or asynchronous, or if an error occurred that prevented the operation from being performed.
+
+Get session operation :
+@code
+odp_crypto_op_t odp_crypto_session_get_op(odp_crypto_session_t ses);
+@endcode
+
+Get session cipher information :
+@code
+odp_cipher_alg odp_cipher_session_get_cipher_alg(odp_crypto_session_t ses);
+@endcode
+
+Get session authentication information :
+@code
+odp_auth_alg odp_crypto_session_get_auth_alg(odp_crypto_session_t ses);
+@endcode
+
+Change session IV :
+@code
+int odp_crypto_session_iv_set(odp_crypto_session_t ses, uint8_t *iv);
+@emdcode
+
+Change cipher or/and hash keys:
+@code
+int odp_crypto_session_key_set(odp_crypto_session_t ses, odp_key_t *key);
+@endcode
+
+Destroy crypto session. 
+All pending operations are cancelled.
+@code
+int odp_crypto_session_destroy(odp_crypto_session_t ses);
+@endcode
+
+Get completion event information - algorithm error, output and context. 
+Note that implementations MAY define their own specific error codes that have meaning in that context. 
+For application portability it is sufficient to know whether an operation completed successfully or experienced an error of some sort.
+@code
+enum crypto_alg_err {
+        ODP_CRYPTO_ALG_ERR_NONE,
+        ODP_CRYPTO_ALG_ERR_MODE,
+        ODP_CRYPTO_ALG_ERR_DATA_SIZE,
+        ODP_CRYPTO_ALG_ERR_KEY_SIZE,
+        ODP_CRYPTO_ALG_ERR_ICV_CHECK,
+        ODP_CRYPTO_ALG_ERR_AAD_SIZE,
+};
+
+enum crypto_hw_err {
+        ODP_CRYPTO_HW_ERR_NONE,
+        ODP_CRYPTO_HW_ERR_DMA,
+        ODP_CRYPTO_HW_ERR_BP_DEPLETED,
+};
+
+struct odp_crypto_compl_status {
+        odp_crypto_alg_t alg;
+        enum crypto_alg_err alg_err;
+        enum crypto_hw_err hw_err;
+};
+
+void
+odp_crypto_get_compl_status(odp_buffer_t completion_event, 
+        struct odp_crypto_compl_status *auth,
+        struct odp_crypto_compl_status *cipher);
+@endcode
+
+Returns the output packet handle associated with the completion event :
+@code
+odp_packet_t odp_crypto_get_out_pkt(odp_buffer_t completion_event);
+@endcode
+
+Sets a context handle to be returned with the completion event :
+@code
+void odp_crypto_set_compl_ctx(odp_buffer_t completion_event, odp_compl_ctx_t *ctx);
+@endcode
+
+Returns the context associated with the completion event :
+@code
+odp_compl_ctx_t odp_crypto_get_compl_ctx(odp_buffer_t completion_event);
+@endcode
+
+This section describes the API/Interface being defined at a functional level in technical detail. 
+Sub-sections include header file names, where implementation files are expected to reside in the ODP git tree, as well as the name, parameters, abstract data types, functionality, return codes, and exception conditions of each function call defined by the API/Interface. 
+Appropriate diagrams, tables, etc. should be used to allow the programmer tasked with implementing the API/Interface to understand the function to be implemented as well as error conditions, corner cases, performance requirements, etc. needed to implement the described API/Interface in a functionally correct and efficient manner.  
+
+@subsubsection random_number_functions Random Number Functions
+As noted earlier, random number support consists of two functions:
+@code
+int odp_hw_random_get (uint8_t *buf, uint32_t *len, bool use_entropy);
+
+int odp_drgb_random_get (uint8_t *buf, uint32_t *len);
+@endcode
+
+The difference is that the first provides access to hardware random number functions that return true random data. 
+This is typically used for seed values. 
+The second provides a deterministic random bit generator conforming to NIST standards and is used by various crypto protocols and algorithms. 
+The use_entropy parameter on odp_hw_random_get is used to disable any hardware pre-processing normally provided by the function and is mainly intended to be used for testing/validation purposes.
+
+@subsubsection buffer_pool_extensions Buffer Pool Extensions
+To support zeroization a buffer may be allocated with an ODP_CLEAR_ON_FREE attribute that specifies that this buffer should be zeroized upon free. 
+Alternately, a new type (ODP_CLEAR_ON_FREE) is added to odp_buffer_pool_create() that specifies that all buffers allocated from this pool must be zeroized upon free. 
+Essentially, the buffer security attribute is set by default from the attributes of the buffer pool that it is allocated from.
+
+@subsubsection capability_inquiry Capability Inquiry
+To enable applications to determine crypto capabilities.
+@code
+int odp_crypto_inquire (enum odp_cipher_alg, enum odp_auth_alg);
+@endcode
+
+Inquires whether the specified crypto and auth algorithms are supported. 
+Responses include:
+- ODP_HW_SYNC_SUPPORT
+- ODP_HW_ASYNC_SUPPORT
+- ODP_SW_SYNC_SUPPORT
+- ODP_SW_ASYNC_SUPPORT
+- ODP_NO_SUPPORT
+
+HW support means the combination is supported in hardware, SW support means the combination is supported in software by the implementation. 
+No support means the combination is not supported by the implementation. 
+The SYNC and ASYNC return options can help the application decide how to invoke these functions, or it can just check whether or not the response is ODP_NO_SUPPORT.
+
+@section implementation_considerations Implementation Considerations
+One of the main purposes for the ODP crypto APIs is to provide portable access across different SoCs whose hardware crypto capabilities largely overlap but vary in terms of their implementation details. 
+As a result, implementations need not provide software fill-ins for specific cryptographic features that are not available as hardware features on that platform. 
+Presumably applications needing specific features will select platforms on which these features are present. 
+Therefore, while all APIs specified here MUST exist in each conforming ODP implementation, it is acceptable for these APIs to return ODP_RC_FEATURE_NOT_PRESENT in response to calls requesting crypto features not present on that platform.
+
+For example, the linux-generic ODP implementation may only implement the null cipher suite (ODP_CIPHER_ALG_NULL) and return a feature not present error code for any other cipher. 
+This indication will also be returned on that platform in response to odp_crypto_inquire calls for non-null cipher algorithms.
+
+@section verification Verification/Testing
+This section describes the verification/test cases needed to ensure that the defined functionality is implemented correctly and performs adequately. 
+This should be at a level of detail such that the programmer tasked with writing test scripts/programs to verify the implementation(s) of the defined functions can be written to ensure that all relevant functional variants and error/exception cases are properly tested.
+
+This section needs to be completed before API testing begins.
+
+*/
