1. The slides following summarize the changes the OCA Alliance is proposing for
AES The Alliance's name for the proposal is OCA 1.4.
We have from the Alliance proposed new versions of
AES70 Part 1 (Framework)
AES70 Part 2, notably including AES70 Part 2 Annex A (class structure)
AES70 Part 3 (OCP.1 Protocol)

2. Change Areas Connection management 3 (CM3) Time and clocking
Reusable blocks
Task support and revised ramper class
Improved proprietary class IDs
Property-change subscriptions
UDP transport option for OCP.1
WebSocket transport option for OCP.1
Many small corrections, clarifications, and improvements

3. Status of OCA 1.4
Parts 1, 2, 2 Annex A, and 3 have been sent to the Standards Office.
As a result of an OCA Alliance Technical F2F meeting yesterday, a slightly revised Part 2 Annex A will be submitted in a few days.
This summary refers to the revised version.
OCA 1.4 will not be available for public download via the Alliance website.

4. More Detailed Summaries of Changes

5. 1. Connection management 3 (CM3)
New connection management object model
Created based on experiences in using AES70 with AES67
Features
More memory- and processor-efficient
Better support for connection negotiation
Easier to use and more flexible clocking support
Easier to program
Can run side-by-side with previous (CM2) connection management
CM2 classes are still in the standard, but deprecated
CM1 refers to a pre-standard scheme that was used in early adoptions

6. 2. Time and clocking New media clock class OcaMediaClock3
Describes a media (sample) clock
New time source class OcaTimeSource
Describes a time source (i.e. reference clock) from which the device or a part of the device learns the correct time.
Features
Generalized and logically corrected representation of clocks & sources
Compatible with AES67, Dante, and AVB clocking architectures
Better support for products that deal with multiple clocks
Aligned with RFC7273, the IETF clock source description standard
Generally cleaner

7. 3. Reusable blocks
Concept: Globally identified OcaBlock instance definition that can be reused across products and, when desired, manufacturers.
New OcaBlock parameter GlobalType
GlobalType is a structured globally unique identifier that identifies the particular structure of a block.
GlobalType includes an IEEE organization ID, so that proprietary values are always globally unique.
Features
Proper management of GlobalType values will allow manufacturers and associations to create standard blocks for specific purposes.
Example: the OCA Alliance could create and publish a set of standard blocks for using CM3 with AES67

8. 4. Task support and redefined ramper class
Concept: OCA support for "tasks", which are processes that run over time.
New Agent classes OcaTask and OcaTaskGroup, new Manager OcaTaskManager
A task has an optional start time, an optional duration, and various states.
Mechanism includes support for managing task execution and resource use.
OcaRamper replaced by OcaRampTask, a subclass of OcaTask

9. 5. Improved form for proprietary class IDs
In AES , proprietary class ID values could clash when proprietary classes from multiple sources existed in the same device.
For AES , the class ID format has been (compatibly) revised to include an IEEE organization ID (OUI or CID) for disambiguation purposes.
This will be particularly useful if/when professional or trade organizations such as the AES or the OCA Alliance want to define classes that are not part of the standard, but nonetheless broadly useful - for example, the subclasses that are defined as part of the AES67 CM3 Adaptation.

10. 6. Property-change subscriptions
In AES , controllers could only subscribe to specific objects.
A subscribed object would then generate a property-change notification when any of its properties changed.
In some cases, this generated many unneeded events.
A new pair of methods, AddPropertyChangeSubscription and DeletePropertyChangeSubscription, have been added to OcaSubscriptionManager.
These methods allow controllers to subscribe to changes for specific properties of a subscribed object, so that only the required notifications will be generated..

11. 7. UDP transport option for OCP.1
In AES , OCP.1 protocol traffic was required to use TCP.
This posed an overhead problem for very small processors without complete TCP stacks, and/or without enough memory for adequate TCP buffer storage.
For AES , the proposed Part 3 allows the option of using UDP instead.
Using UDP will not be as reliable as using TCP, but since OCP.1 is a fully acknowledged protocol, the impact will be small in most cases.
A secure option for UDP has not been defined.

12. 8. WebSocket transport option for OCP.1
In AES , OCP.1 protocol traffic was required to use TCP.
For AES , the proposed Part 3 allows the option of using WebSocket, the HTTP-mediated version of TCP.
The purpose of this addition is to make it easier for web browsers to run applications that talk directly to devices.
Normal web browser sandboxes do not allow browser-based code to open TCP connections, but they do allow opening of WebSocket connections.
The programming overhead of using WebSocket is low.
The device must include a tiny HTTP server that performs a simple negotiation to set up the WebSocket channel.
After the negotiation, TCP traffic flows essentially normally.
WebSocket traffic is record-oriented, rather than stream-oriented. This is actually easier for small devices to handle.

13. 9. Small changes, corrections, and improvements
Various datatyping errors have been corrected.
Spelling and case errors have been fixed.
Comments have been corrected and enhanced in the Part 2 UML file.
A few semantic omissions and unclarities in Part 1 have been fixed.
In Part 3, marshalling rules have been clarified.
The Part 2 UML specification now contains ordinal numbers that precisely define the order of datatype and parameter marshalling.