2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 1 Presentation to SC25/WG1 On Interoperability (18012-2) and DCTP (Command/Control

2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.

1

Presentation to SC25/WG1 OnInteroperability (18012-2) and DCTP

(Command/Control Services/Protocols)

Presentation By Frank Farance, Farance Inc.+1 212 486 4700, [email protected]


2

Background Information on 15067-1

• Data and Control Transfer Protocol (DCTP)• Based on work by Simon Garrett and other

contributions• Concerns interoperability (roughly layer 5)• ISO OSI stack is not implied, e.g., RS-232

transport is possible


3

What DCTP Does

• Common method for get/put values– Both numeric and non-numeric values

• Common method for passing params/control• Common framework for security (“plug-ins”)• Various connection frameworks

– connection vs. connectionless– point-to-point vs. broadcast– connected vs. roaming vs. sometimes-connected– bus vs. ring vs. point-to-point connectivity– depends upon underlying communications

• Very simple implementation paradigm– Supports low-memory, embedded systems– Data and control paradigms


4

What DCTP Does Not Do

• DCTP does not determine lexicon, e.g.,– Names of parameters– Acceptable values

• DCTP does not define naming of objects• DCTP does not require specific security services• DCTP does not specify transport facilities• DCTP does not mandate proprietary systems

change — gateways/virtualization is possible


5

Applications of DCTP

• Command and control (C2) for appliances/devices– Set/retrieve values– May be used for smart/dumb devices

• Bridging protocol/services among proprietary protocols/services

• DCTP can be “lower” level protocol support for higher APIs


6

How the Pieces Fit Together

Device/Ctrl #1

Device/Ctrl #2

Process:18012-4

Coding:18012-2 (lexicon)

ConformsTo “Registry”

Command/Control

e.g.,15067-1DCTP

Process: Determines what is entered in registry

Registry: Valid code sets; extension mechanism

Command/Control Protocol: Protocol binding of 18012-1, using 18012-2 codesets (lexicon), as maintained by 18012-4 process

Applications: Claim conformance to: 18012-2, 15067-1

Creates/Administers

Consensus-BuildingProcess

Registry(table)


7

Relationship to 18012 Interoperability

• Current 18012 status:– Part 1: Introduction– Part 2: Taxonomy and Lexicon– Part 3: Application Models

• At both 2001-01 and 2001-06 SC25/WG1, it was suggested that Part 4 be added:– Part 4: Registration Authority– Simplifies adoption and maintenance of 18012

series of documents


8

Example DCTP Binding of 18012

• Generically, the binding might look like:– PVAL lexicon_object lexicon_value

• Assuming registered in 18012-2 lexicon:– “LAMP” is a registered object– “OFF” and “ON” are registered values causing

actions “off” and “on”• Sample messages:

– PVAL LAMP OFF– PVAL LAMP ON

• MDAS (ISO/IEC 20944-*) binding:– mdas_putvalue(“LAMP”,“OFF”)– mdas_putvalue(“LAMP”,“ON”)


9

Methodology: Work Flow And Progressive Deliverables

Requirements

Functionality

Conceptual Model

Semantics

Bindings: APIs Bindings: Codings Bindings: Protocols

Encodings:Data Formats

Encodings: CallingConventions

Encodings: VariousCommunication Layers

The Steps of Building SuccessfulInformation Technology Standards/Specifications

“The work flow/steps promote(1) consensus-building, and

(2) long-term stability, interpretation, maintenance of

the standard/specification.”

“Consensus-building is incremental.”

“Interpretation/maintenance is stabilized: each level is dependent on higher levels.”

“Interpretation Examples:- Ambiguities in bindings are resolved by interpreting the semantics;- Ambiguities in semantics are resolved by interpreting the conceptual model.”


10

A Framework for Harmonized/Consistent ...Bindings: Codings, APIs, Protocols

Encodings: Calling Conventions, Data Formats, Communication Layers

Topic-SpecificInformative Wording

Topic-SpecificNormative Wording

Cross-TopicCodings: XML

Cross-Topic APIsInformative Wording

Cross-Topic APIs:Normative WordingJava, JavaScript,C/C++, Perl, Tcl, VB

Various Standards

Cross-Topic Protocolse.g.: Session Layers

Various Standards

Requirements

Functionality

Conceptual Model

Semantics

Bindings: Codings Bindings: Protocols



Bindings: APIs

Encodings:Calling Conventions


11Relatively Dynamic

Relatively Static

Long-Term vs. Short-Term SpecsStrategy for Keeping Pace With Technology






Various Standards


Various Standards

Requirements

Functionality

Conceptual Model

Semantics




Bindings: APIs



12

Interoperability (18012-1) Represents Higher Levels






Various Standards


Various Standards

Requirements

Functionality

Conceptual Model

Semantics




Bindings: APIs



13

Data and Control Transfer Protocol(DCTP, ISO/IEC 15067-1) Is “Protocol-Like”






Various Standards


Various Standards

Requirements

Functionality

Conceptual Model

Semantics




Bindings: APIs



14

Metadata Access Service (ISO/IEC 20944) Is “API-Like”






Various Standards


Various Standards

Requirements

Functionality

Conceptual Model

Semantics




Bindings: APIs



15

APIs, Codings, Protocols —All Three Should Be Considered

Semantics

Bindings: APIs

Bindings: Codings

Bindings: Protocols

- Std APIs may be implemented viastd or proprietary Protocols- Std Protocols may be accessedby std or proprietary APIs- Both std APIs/Protocols improvewide area interoperability

- Std APIs may use std orproprietary Codings- Std Codings may be usedby std or proprietary APIs- Both std APIs/Codingsimprove portable apps/data

- Std Protocols may use std orproprietary Codings- Std Codings may be exchangedvia std or proprietary Protocols- Both std Protocols/Codingsimprove system interoperability

Harmonized standard APIs, Codings,and Protocols promote:- Application portability- Data portability- Multi-vendor, “open” solutions- Wide area, end-to-end interoperability

Prioritizing The Development OfStandards for Codings, APIs, and Protocols


16

Building Standards InSeveral Steps

Maintenance

Development

Review

Amendments: 2-3 yearsRevisions: 4-5 years

ConsensusBuilding

User/Vendor/Institutional/

Industry“Extensions”

“Extensions” Become Input ToNext Revision Of Standard

Industry-Relevant,Widely-Adopted

“Extensions”

The “Standard”


17

Metadata Access Service(MDAS, ISO/IEC 20944-x)

• Requirements– Make inquiries into repositories to determine

metadata– Use metadata for further interoperability of

repositories– Help facilitate metadata/data interchange among

repositories– Harmonize with semi-structure data access– Harmonize with lexicon query service, terminology

services


18


• Functionality– Interacts directly with repositories– Get (and put) metadata/data– Specialized query features to handle:

• Search by type• Search by identifier• Search by label• Search by property (attribute)


19


• Semantics Summary– Currently being refined,

based on SDA API, LQS, DCTP, etc.

– Work being harmonized with ISO 15067-1 (DCTP being incorporated)

• RESOLVE: connect to repository• OPEN: begin access to repository• SET: set protocol parameters• QUERY: query protocol parameters• GIVEAUTH, NEEDAUTH:

authentication/authorization• NOMAD: nomadic (disconnected)

access• CV: change view (directory)• GETVAL: get info from repository• PUTVAL: put info to repository• LIST: retrieve names in repository• EVENT: client and server event

processing• CLOSE: end access to repository• UNRESOLVE: disconnect from

repository


20

DCTP (15067-1) Messages Summary• CONN (connect): Connection to “repository”

– Can be ignored for simple controllers• OPEN (open): Establish session

– Can support multiple sessions– Simple controllers need only support single session

• RQAU: Request authentication/authorization– Security request

• RSAU: Respond authentication/authorization– Security response

• CLOS (close): Close session– Simple controllers can ignore

• DISC (disconnect): Disconnect from “repository”– Simple controllers can ignore


21

DCTP (15067-1) Messages Summary

• GSES: Get session parameters– Can be very simplistic

• PSES: Put session parameters– Can support multiple sessions– Simple controllers need only support single session

• GVAL: Get value (retrieve, variety of types)– Simple to implement for simple controllers

• PVAL: Put value (store, variety of types)– Simple to implement for simple controllers


22

DCTP (15067-1) Messages Summary

• LSOB: List “objects”– Easy to implement

• MKOB: New (make “object”)– Simple controllers can ignore

• RMOB: Destroy (remove “object”)– Simple controllers can ignore

• NOMD: Nomadic connection setup– Simple controllers can ignore

• GPTH: Get current path/view– Simple response for simple controllers

• PPTH: Put current path/view– Simple controllers can ignore


23

Sample Messages

OPENGVAL xyzPVAL xyz 123PVAL abc “off”


24

Integration With HomeGate

• Used inside the residential gateway• Can be used to bridge subnets for command

and control• Can be used an an intermediate language• Should be a standard, not a technical report• Definitely normative wording: implementations

will want to claim conformance


25

Integration With HomeGate

• Not required in a residential gateway because systems can choose to conform (or not) to ISO/IEC 15067-1

• Components can use proprietary bridging mechanism, if desired

• DCTP allows vendors to build “half-bridges” among subnets, which reduces integration complexity to N, not N*N

• Implementations already in C, C++, Perl, Java — all are small code size


26

Status of 15067-1 Document

• Draft 1, dated 2001-06-04• Draft 2, dated 2001-12-22

– Minor wording polishing/improvements– Fixing inconsistencies with 11404 datatyping– Add wording to explain enum lists and prop lists– Rename “name” to “label” in the metadata– Fill in some of the holes

• Draft 3, target 2002-05 (in time for 2002-06 mtg)

– Establish editing/review committee (telecons)– Finish “to be supplied” items

Documents

2002-01-24SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc. 1 Presentation to SC25/WG1 On Interoperability (18012-2) and DCTP (Command/Control