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]
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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)
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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”)
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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.”
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
Encodings: VariousCommunication Layers
Encodings:Data Formats
Bindings: APIs
Encodings:Calling Conventions
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
11Relatively Dynamic
Relatively Static
Long-Term vs. Short-Term SpecsStrategy for Keeping Pace With Technology
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
Encodings: VariousCommunication Layers
Encodings:Data Formats
Bindings: APIs
Encodings:Calling Conventions
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
12
Interoperability (18012-1) Represents Higher Levels
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
Encodings: VariousCommunication Layers
Encodings:Data Formats
Bindings: APIs
Encodings:Calling Conventions
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
13
Data and Control Transfer Protocol(DCTP, ISO/IEC 15067-1) Is “Protocol-Like”
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
Encodings: VariousCommunication Layers
Encodings:Data Formats
Bindings: APIs
Encodings:Calling Conventions
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
14
Metadata Access Service (ISO/IEC 20944) Is “API-Like”
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
Encodings: VariousCommunication Layers
Encodings:Data Formats
Bindings: APIs
Encodings:Calling Conventions
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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”
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
18
Metadata Access Service(MDAS, ISO/IEC 20944-x)
• 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)
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
19
Metadata Access Service(MDAS, ISO/IEC 20944-x)
• 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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
23
Sample Messages
OPENGVAL xyzPVAL xyz 123PVAL abc “off”
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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
2002-01-24 SC25/WG1/N1007, Presentation on Command/Control, ©2002 Farance Inc.
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