The slides following summarize the changes the OCA Alliance is proposing for AES70-2017. 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)

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

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.

More Detailed Summaries of Changes

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

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

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

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

5. Improved form for proprietary class IDs In AES70-2015, proprietary class ID values could clash when proprietary classes from multiple sources existed in the same device. For AES70-2015, 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.

6. Property-change subscriptions In AES70-2015, 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..

7. UDP transport option for OCP.1 In AES70-2015, 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 AES70-2017, 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.

8. WebSocket transport option for OCP.1 In AES70-2015, OCP.1 protocol traffic was required to use TCP. For AES70-2017, 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.

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.