The OCF Core Framework is an IoT framework for device discovery, on-boarding and application-layer security, for device-to-device and device-to-cloud connectivity. It can be used with any application layer, using your own data models. The OCF Core Framework is published as a ISO/IEC standard, there is a compliant open source stack and a comprehensive certification program in place.
OCF is promoting the OCF Core Framework as a unique secure framework, many IoT projects fail to the lack of security.
The OCF Core Framework is designed with best of security in mind.
The OCF secure domain is a set of OCF devices that can securely talk to each other.
For example: all devices have credentials configured in such way that the communication between the devices are secure. In proximal networks the secure links are based on IETF DTLS. Getting on the secure domain is done via the onboarding tool (OBT). Multiple secure domains can exist on the same network.
Although all devices in the secure domain can establish secure communication, not all devices should be able to talk to each other. Hence Access Control List are an integral part of the OCF security principles, it allows configuration of access the OCF Servers by the OCF Clients. This is done per Resource & operations that are possible on the resources.
The current set of onboarding mechanism do not require internet access.
However, the proving of identity (checking the device PKI certificate) of the device to be onboarded might require internet access in the future.
CRUDN stands for Create, Read, Update, Delete, Notify operations.
By having this abstraction layer in the specifications, these operations are agnostic defined from the actual used HTTP or CoAP protocol.
At this moment the OCF Coe Framework is using CoAP, since that can be seen as an optimal technology for IoT. CoAP is using binary (e.g. more compact as HTTP) and can send confirmable (reliable) and non-confirmable message (send and forget). Also, CoAP has Observe which can be used for notifications. Observe is similar as an HTTP long poll that can be used to send updates to the client.
OCF discovery is used to discover which other OCF devices are on the network. OCF Discovery is on the device to list which resource (functionality) is being exposed by the device. These 2 distinct functions are integrated by the OCF Core Framework: detecting the devices on the network, the devices will respond with all the implemented functionalities.
No, OCF is using IPV6 addressing. All the devices have a unique device identifier though, so that can be used in code to reference a specific device instance.
The OCF specs are created on a few principles: do not reinvent new technology, use existing tech as much as possible. Hence OCF integrated lots of IETF related specifications: CBOR, CoAP, DTLS etc. The OCF specs creates from the referenced technologies overarching architecture, e.g. defines how to use the individual technologies as a full-fledged IoT architecture.
Yes, the OCF Core Framework components are created in a rest full manor on top of CoAP. Any integration on top of TCP/UDP can be used.
The application layer though can be non-rest full for example it can work with SOAP.
The OCF Core Framework is created with UDP/CoAP using JSON defined payloads encoded in CBOR. There is a lot of experience and examples using this approach. However, HTTP or UDP/TCP layers as integration section can be used as well.