< draft-vanderstok-core-bc-04.txt   draft-vanderstok-core-bc-05.txt >
CoRE P. van der Stok CoRE P. van der Stok
Internet-Draft Philips Research Internet-Draft Philips Research
Intended status: Informational K. Lynn Intended status: Informational K. Lynn
Expires: January 12, 2012 Consultant Expires: May 2, 2012 Consultant
July 11, 2011 October 30, 2011
CoAP Utilization for Building Control CoAP Utilization for Building Control
draft-vanderstok-core-bc-04 draft-vanderstok-core-bc-05
Abstract Abstract
This draft describes an example use of the RESTful CoAP protocol for This draft describes an example use of the RESTful CoAP protocol for
building automation and control (BAC) applications such as HVAC and building automation and control (BAC) applications such as HVAC and
lighting. A few basic design assumptions are stated first, then URI lighting. A few basic design assumptions are stated first, then URI
structure is utilized to define group as well as unicast scope for structure is utilized to define group as well as unicast scope for
RESTful operations. RESTful operations.
The authority portion of the URI is used to identify a device (group)
and the resulting DNS name is bound to a unicast (multicast) address.
Naming is building or organization dependent, must be flexible, and
does not require standardization efforts but SHOULD conform to some
uniform convention.
It is shown that DNS-based service discovery can be used to locate
URIs on the scale necessary in large commercial BAC deployments.
Finally, a method is proposed for mapping URIs onto legacy BAC
resources, e.g., to facilitate application-layer gateways.
This proposal supports the view that 1) service discovery is This proposal supports the view that 1) service discovery is
complementary to resource discovery and facilitates control network complementary to resource discovery and facilitates control network
scaling, and 2) building control is likely to move in steps toward scaling, and 2) building control is likely to move in steps toward
all-IP control networks based on the legacy efforts provided by DALI, all-IP control networks based on the legacy efforts provided by DALI,
LON, BACnet, ZigBee, and other standards, LON, BACnet, ZigBee, and other standards.
The authority portion of the URI is used to identify a device (group)
and the resulting DNS name is bound to a unicast (multicast) address.
Group addressing has consequence for the naming convention of the
resources of a device. Naming of URI is building or organization
dependent, must be flexible, and SHOULD conform to some local
convention. Naming of resources MUST be standardised preferrable by
a building control related organisation.
It is shown that DNS-based service discovery can be used to locate
URIs on the scale necessary in large commercial BAC deployments. The
relation of DNS-SD and a Resource Directory is discussed. Finally, a
method is proposed for mapping URIs onto legacy BAC resources, e.g.,
to discover application-layer gateways, proxies, and their dependent
services.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on May 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
2. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 6 2. URI structure . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scheme part . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scheme part . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Authority part . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Authority part . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Path part . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Path part . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Group Naming and Addressing . . . . . . . . . . . . . . . . . 10 3. Group Naming and Addressing . . . . . . . . . . . . . . . . . 10
4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Service discovery goals . . . . . . . . . . . . . . . . . 12 4.1. Service discovery goals . . . . . . . . . . . . . . . . . 12
4.2. DNS-Based Service Discovery . . . . . . . . . . . . . . . 13 4.2. DNS-Based Service Discovery . . . . . . . . . . . . . . . 13
4.3. Service vs Host Names . . . . . . . . . . . . . . . . . . 14 4.3. Browsing for Services . . . . . . . . . . . . . . . . . . 14
4.4. Browsing for Services . . . . . . . . . . . . . . . . . . 15 4.4. Resource vs Service Discovery . . . . . . . . . . . . . . 14
4.5. Resource vs Service Discovery . . . . . . . . . . . . . . 15 5. DNS record structure . . . . . . . . . . . . . . . . . . . . . 15
5. DNS record structure . . . . . . . . . . . . . . . . . . . . . 16 5.1. DNS group example . . . . . . . . . . . . . . . . . . . . 18
5.1. DNS group example . . . . . . . . . . . . . . . . . . . . 19 5.2. Operational use of DNS-SD . . . . . . . . . . . . . . . . 19
5.2. Operational use of DNS-SD . . . . . . . . . . . . . . . . 20
5.3. Commissioning CoAP devices . . . . . . . . . . . . . . . . 20 5.3. Commissioning CoAP devices . . . . . . . . . . . . . . . . 20
5.3.1. DNS-SD server present . . . . . . . . . . . . . . . . 21 5.3.1. DNS-SD server present . . . . . . . . . . . . . . . . 21
5.3.2. DNS-SD server not present . . . . . . . . . . . . . . 22 5.3.2. DNS-SD server not present . . . . . . . . . . . . . . 21
5.4. Proxy discovery . . . . . . . . . . . . . . . . . . . . . 22 5.4. Proxy discovery . . . . . . . . . . . . . . . . . . . . . 22
6. Legacy data Representations in CoAP . . . . . . . . . . . . . 24 6. Legacy data Representations in CoAP . . . . . . . . . . . . . 23
6.1. Network architectures . . . . . . . . . . . . . . . . . . 24 6.1. Network architectures . . . . . . . . . . . . . . . . . . 24
6.2. Gateways to legacy networks . . . . . . . . . . . . . . . 26 6.2. Discovery of legacy gateways . . . . . . . . . . . . . . . 26
6.3. Discovery of legacy gateways . . . . . . . . . . . . . . . 27 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Security considerations . . . . . . . . . . . . . . . . . . . 27
8. Security considerations . . . . . . . . . . . . . . . . . . . 29 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
In addition, the following conventions are used in this document: In addition, the following conventions are used in this document:
A CoAP end-point, or server, is identified by a unique {IP address, A CoAP end-point, or server, is identified by a unique {IP address,
port} tuple. A server is completely specified by the authority part port} tuple and characterised by a protocol. A server is completely
of a URI. specified by the authority part of a URI.
A device is the physical object that is connected to the network. A A device is the physical object that is connected to the network. A
device may host one or more CoAP servers. device may host one or more CoAP servers.
A service (in the service discovery sense) is a related set of A service (in the service discovery sense) is a related set of
resources on a CoAP server. A URI completely specifies the syntax of resources on a CoAP server. A URI completely specifies the syntax of
a service interface. Metadata describe the semantics of the service a service interface. Metadata describe the semantics of the service
interface. The semantics may include the relation between service interface. The semantics may include the relation between service
and the hardware connected to the device. A CoAP server may expose and the hardware connected to the device. A CoAP server may expose
one or more services. one or more services.
skipping to change at page 5, line 24 skipping to change at page 5, line 24
function invocation. Many of these industry standards also specify function invocation. Many of these industry standards also specify
proprietary transport protocols, necessitating expensive stateful proprietary transport protocols, necessitating expensive stateful
gateways for these standards to interoperate. Many more recent gateways for these standards to interoperate. Many more recent
building control network include IP-based standards for transport (at building control network include IP-based standards for transport (at
least to interconnect islands of functionality) and other functions least to interconnect islands of functionality) and other functions
such as naming and discovery. CoAP will be successful in the such as naming and discovery. CoAP will be successful in the
building control market to the extent that it can represent a given building control market to the extent that it can represent a given
standard's data objects and provide functions, e.g. resource standard's data objects and provide functions, e.g. resource
discovery, that these standards depend on. discovery, that these standards depend on.
From the above the basic syntax properties can be summarized as: From the above the wanted basic syntax properties can be summarized
as:
- Generate small payloads. - Generate small payloads.
- Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee - Compatible with legacy standards (e.g. LON, BACnet, DALI, ZigBee
Device Objects). Device Objects).
- Service/resource discovery in agreement with legacy standards and - Service/resource discovery in agreement with legacy standards and
naming conventions. naming conventions.
This submission defines an approach in which the payload contains This submission defines an approach in which the payload contains
messages with a syntax defined by legacy control standards. messages with a syntax defined by legacy control standards.
Accordingly, the syntax of the service/resource discovery messages Accordingly, the syntax of the service/resource discovery messages
skipping to change at page 6, line 49 skipping to change at page 7, line 7
standard DNS host naming, while the path is valid in relation to a standard DNS host naming, while the path is valid in relation to a
fully qualified domain name (FQDN) plus optional port (and protocol fully qualified domain name (FQDN) plus optional port (and protocol
is implicit, based on scheme). An example based on [RFC3986] is: is implicit, based on scheme). An example based on [RFC3986] is:
foo://host.example.com:8042/over/there?name=ferret#nose, where "foo" foo://host.example.com:8042/over/there?name=ferret#nose, where "foo"
is the scheme, "host.example.com:8042" is the authority, "/over/ is the scheme, "host.example.com:8042" is the authority, "/over/
there" is the path, "name=ferret" is the query, and "nose" is the there" is the path, "name=ferret" is the query, and "nose" is the
fragment. Fragments are not supported in CoAP. fragment. Fragments are not supported in CoAP.
2.1. Scheme part 2.1. Scheme part
The CoAP URI scheme syntax is specified in section 6.1 of The CoAP URI scheme syntax is specified in section 6 of
[I-D.ietf-core-coap] and is compatible with the "http" scheme [I-D.ietf-core-coap] and is compatible with the "http" scheme
specification [RFC2616]. The scheme is implicit from the perspective specification [RFC2616]. The scheme is implicit from the perspective
of the service, but it indicates the protocol used to access the of the service, but it indicates the protocol used to access the
service to potential clients. service to potential clients.
TBD: we have yet to fully explore the utility of a separate scheme
(e.g., "coapm") to support group communication models as described in
[I-D.rahman-core-groupcomm].
2.2. Authority part 2.2. Authority part
The authority part is either a literal IP address or a DNS name The authority part is either a literal IP address or a DNS name
comprised of a local part, specifying an individual device or group comprised of a local part, specifying an individual device or group
of devices, and a global part specifying a (sub)domain that may of devices, and a global part specifying a (sub)domain that may
reflect the logical hierarchical structure of the building control reflect the logical hierarchical structure of the building control
network. The result is said to be a fully qualified domain name network. The result is said to be a fully qualified domain name
(FQDN) which is globally unique down to the group or device level. (FQDN) which is globally unique down to the group or device level.
An optional port number may be included in the authority following a An optional port number may be included in the authority following a
single colon ":" if the service port is other than the default CoAP single colon ":" if the service port is other than the default CoAP
skipping to change at page 7, line 47 skipping to change at page 7, line 48
A building can be unambiguously addressed by it GPS coordinates or A building can be unambiguously addressed by it GPS coordinates or
more functionally by its zip or postal code. For example the Dutch more functionally by its zip or postal code. For example the Dutch
Internet provider, KPN, assigns to each subscriber a host name based Internet provider, KPN, assigns to each subscriber a host name based
on its postcode. Analogously, an example authority for a building on its postcode. Analogously, an example authority for a building
may be given by: //bldg.zipcode-localnr.Country/ or more concretely may be given by: //bldg.zipcode-localnr.Country/ or more concretely
an imaginary address in the Netherlands as: //bldg.5533BA-125a.nl/. an imaginary address in the Netherlands as: //bldg.5533BA-125a.nl/.
The "bldg" prefix can specify the target device within the building. The "bldg" prefix can specify the target device within the building.
Arriving at the device identified by //bldg.5533BA-125a.nl, the Arriving at the device identified by //bldg.5533BA-125a.nl, the
receiving service can parse the path portion of the URI and perform receiving service can parse the path portion of the URI and perform
the requested method on the specified resource. the requested actions on the specified resource.
Buildings have a logical internal structure dependent on their size Buildings have a logical internal structure dependent on their size
and function. This ranges from a single hall without any structure and function. This ranges from a single hall without any structure
to a complex building with wings, floors, offices and possibly a to a complex building with wings, floors, offices and possibly a
structure within individual rooms. The naming of the building structure within individual rooms. The naming of the building
control equipment and the actual control strategy are intimately control equipment and the actual control strategy are intimately
linked to the building structure. It is therefore natural to name linked to the building structure. It is therefore natural to name
the equipment based on their location within the building. the equipment based on their location within the building.
Consequently, the local part of the URI identifying a piece of Consequently, the local part of the URI identifying a piece of
equipment is expressed in the building structure. An example is: equipment is expressed in the building structure. An example is:
skipping to change at page 8, line 34 skipping to change at page 8, line 34
Most communication is device to device (M2M) within the building. Most communication is device to device (M2M) within the building.
Often a device needs to communicate to all devices of a given type Often a device needs to communicate to all devices of a given type
within a given area of the building. For example a thermostat may within a given area of the building. For example a thermostat may
access all radiator actuators in a zone. A light switch located at access all radiator actuators in a zone. A light switch located at
room 25b006 of floor one, expressed as: room 25b006 of floor one, expressed as:
//switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to //switch0.25b006.floor1.5533BA-125a.nl/, might specify a command to
light1 within the same room with //light1.25b006.floor1.5533BA- light1 within the same room with //light1.25b006.floor1.5533BA-
125a.nl/. This approach can lead to rather verbose URI strings in 125a.nl/. This approach can lead to rather verbose URI strings in
the packet, contrary to the small packet assumption. The question the packet, contrary to the small packet assumption. The question
arises as to whether the syntax of the authority part needs to be arises as to whether the syntax of the authority part needs to be
standardized for building control. Given the examples later in the standardized for building control. Given the naming flexibility
text, naming authorities for building control appears more to be the provided by DNS, authority names for building control are more the
concern of the building owner or the installer than a standardization concern of the building owner or the installer than a standardization
concern. concern.
2.3. Path part 2.3. Path part
The path identifies the addressable attributes of the service at the The path identifies the addressable attributes of the service at the
highest possible granularity. A set of paths defines the syntax of highest possible granularity. A set of paths defines the syntax of
the service invocation and constitutes the interface description of the service invocation and constitutes the interface description of
the service. Every network service attribute is completely the service. Every network service attribute is completely
identified by a URI scheme://authority/path. In analogy, the path identified by a URI scheme://authority/path. In analogy, the path
skipping to change at page 9, line 18 skipping to change at page 9, line 18
a slash, like /func1/subf2/final. The set of paths is structured as a slash, like /func1/subf2/final. The set of paths is structured as
a tree. The last name in a name field sequence is called a leave of a tree. The last name in a name field sequence is called a leave of
the tree, and the authority is the root of the path tree of a given the tree, and the authority is the root of the path tree of a given
host. The semantics of a given sub-tree in the path tree is host. The semantics of a given sub-tree in the path tree is
specified by the Interface Description (if=) attribute described in specified by the Interface Description (if=) attribute described in
[I-D.ietf-core-link-format]. As for file systems some tree naming [I-D.ietf-core-link-format]. As for file systems some tree naming
with associated semantics can be standardized such as the de facto PC with associated semantics can be standardized such as the de facto PC
standard directory "documents and settings" with the sub-directories standard directory "documents and settings" with the sub-directories
"My documents", "usradmin", etc. When a given body, e.g. XXX, has "My documents", "usradmin", etc. When a given body, e.g. XXX, has
defined a name structure and semantics for the path tree, we say that defined a name structure and semantics for the path tree, we say that
"if = XXX" for the path tree conforms to the name structure defined "if = XXX" when the path tree conforms to the name structure defined
by XXX. by XXX.
When a GET method with an URI like When a GET method with an URI like
"//t-sensor1.25b006.floor1.example.com/temperature" is sent, it "//t-sensor1.25b006.floor1.example.com/temperature" is sent, it
represents an a priori understanding that the server with name represents an a priori understanding that the server with name
t-sensor1 exists, provides a service of a given standard type (with t-sensor1 exists, provides a service of a given standard type (with
associated semantics) (e.g. ZigBee temperature sensor), and that associated semantics) (e.g. ZigBee temperature sensor), and that
this standard type has the readable attribute: temperature. When this standard type has the readable attribute: temperature. When
commands are sent to a group of servers it MUST be the case that the commands are sent to a group of servers it MUST be the case that the
targeted resource has the same path on all targeted servers. targeted resource has the same path on all targeted servers.
Therefore, it is necessary to establish at least a local uniform path Therefore, it is necessary to establish at least a local uniform path
naming convention to achieve this. One approach is to include the naming convention to achieve this. One approach is to include the
name of the standard, e.g. BACnet, as the first element in the path name of the standard, e.g. BACnet, as the first element in the path
and then employ the standard's chosen data scheme (in the case of and then employ the standard's chosen data scheme (in the case of
BACnet, /bacnet/device/object/property). BACnet, /bacnet/device/object/property).
The organization responsible for defining a given industry standard The organization responsible for defining a given industry standard
XXX (e.g. BACnet, ZigBee, etc.) can register the /.well-known/XXX XXX (e.g. BACnet, ZigBee, etc.) can register the /.well-known/XXX
prefix and specify the allowable path-names that may occur under this prefix and specify the allowable path-names for a server of a given
prefix. The same body also defines the "if=XXX" attribute. This type. The same body also defines the "if=XXX" attribute. This
allows the standards development organization responsibile for XXX to allows the standards development organization responsibile for XXX to
define the name space and resources associated with the prefix define the name space and resources associated with the prefix
together with the associated semantics. The registered /.well-known/ together with the associated semantics. The registered /.well-known/
XXX URI effectively defines a standard object model, or schema, for XXX URI effectively defines a standard object model, or schema, for
services of the XXX application protocol. Manufacturers may services of the XXX application protocol. Manufacturers may
optionally define proprietary resources that can be discovered optionally define proprietary resources that can be discovered
dynamically using methods described below. dynamically using methods described below.
Although the authority part names need not always be transported, the Although the authority part names need not always be transported, the
path names MUST be transported in the CoAP packets. Therefore, it is path names MUST be transported in the CoAP packets. Therefore, path
advisable to make the resource names as short as possible, even at names SHOULD be as short as possible, even at the detriment of the
the detriment of the clarity of the meaning of the path name. clarity of the meaning of the path name.
3. Group Naming and Addressing 3. Group Naming and Addressing
Within building control it is necessary to send the same command to a Within building control it is necessary to send the same command to a
set of servers or devices. Grouping allows to invoke the set of set of servers. Grouping allows to invoke the set of services with
services with one application command to be executable within a one application command to be executable within a specified time
specified time interval. Given a network configuration, the network interval. Given a network configuration, the network operator needs
operator needs to define an appropriate set of groups which can be to define an appropriate set of groups which can be mapped to the
mapped to the building areas. Knowledge about the hierarchical building areas. Knowledge about the hierarchical structure of the
structure of the building areas may assist in defining a network building areas may assist in defining a network architecture which
architecture which encourages an efficient group communication encourages an efficient group communication implementation. IP-
implementation. IP-multicasting over the group is a possible multicasting over the group is a possible approach for building
approach for building control, although proxy-based methods may prove control, although proxy-based methods may prove to be more
to be more appropriate in some deployments appropriate in some deployments [I-D.rahman-core-groupcomm].
[I-D.rahman-core-groupcomm].
Example device groups become: Example device groups become:
URI authority Targeted group URI authority Targeted group
//all.bldg6... "all devices in building 6" //all.bldg6... "all devices in building 6"
//all.west.bldg6... "all devices in west wing, building //all.west.bldg6... "all devices in west wing, building
6" 6"
//all.floor1.west.bldg6... "all devices on floor 1, west wing, //all.floor1.west.bldg6... "all devices on floor 1, west wing,
..." ..."
//all.bu036.floor1.west.bldg6... "all devices in office bu036, ..." //all.bu036.floor1.west.bldg6... "all devices in office bu036, ..."
skipping to change at page 10, line 40 skipping to change at page 10, line 39
The granularity of this example is for illustration rather than a The granularity of this example is for illustration rather than a
recommendation. Experience will dictate the appropriate hierarchy recommendation. Experience will dictate the appropriate hierarchy
for a given structure as well as the appropriate number of groups per for a given structure as well as the appropriate number of groups per
subdomain. Note that in this example, the group name "all" is used subdomain. Note that in this example, the group name "all" is used
to identify the group of all devices in each subdomain. In practice, to identify the group of all devices in each subdomain. In practice,
"all" could name an address record in each of the DNS zones shown "all" could name an address record in each of the DNS zones shown
above and would bind to a different multicast address [RFC3596] in above and would bind to a different multicast address [RFC3596] in
each zone. Highly granular multicast scopes are only practical using each zone. Highly granular multicast scopes are only practical using
IPv6. The multicast address allocation strategy is beyond the scope IPv6. The multicast address allocation strategy is beyond the scope
of this I-D, but various alternatives have been proposed of this I-D, but various alternatives have been proposed
[RFC3306][RFC3307][RFC3956]. Some techniques in this proposal, e.g. [RFC3306][RFC3307][RFC3956].
service discovery as described below, can be accomplished with a
single CoAP-specific multicast address as long as the desired scope
is building-wide.
To illustrate the concept of multiple group names within a building, To illustrate the concept of multiple group names within a building,
consider the definition, as done with [DALI], of scenes within the consider the definition, as done with [DALI], of scenes within the
context of a floor or a single office. For example, the setting of context of a floor or a single office. For example, the setting of
all blue lights in office bu036 of floor 1 can be realized by all blue lights in office bu036 of floor 1 can be realized by
multicasting a message to the group "//blue-lights.bu036.floor1". multicasting a message to the group "//blue-lights.bu036.floor1".
Each group is associated with a multicast IP address. Consequently, Each group is associated with a multicast IP address. Consequently,
when the application specifies the sending of an "on" message to all when the application specifies the sending of an "on" message to all
blue lights in the office, the message is multicast to the associated blue lights in the office, the message is multicast to the associated
IP address. The URI-Host option [I-D.ietf-core-coap] need not be IP address.
sent as part of the message. However to identify the resource that
is addressed, a short version of the resource path can be inserted as
an option as explained in [I-D.ietf-core-link-format].
The binding of a group FQDN to a multicast address (i.e., creation of The binding of a group FQDN to a multicast address (i.e., creation of
the AAAA record in the DNS zone server) happens during the the AAAA record in the DNS zone server) happens during the
commissioning process. Resolution of the group name to a multicast commissioning process. Resolution of the group name to a multicast
address happens at restart of a device. A multicast address and address happens at restart of a device. A multicast address and
associated group name in this context are assumed to be long-lived. associated group name in this context are assumed to be long-lived.
It can happen that during operation the membership of the group It can happen that during operation the membership of the group
changes (less or more lights) but its address is not altered and changes (less or more lights) but its address is not altered and
neither is its name. In the limit, the group can degrade to a single neither is its name. Group membership may be managed by a protocol
controller that represents a non-networked subsystem replacing the such as Multicast Listener Discovery [RFC5790].
original networked group of devices. Group membership may be managed
by a protocol such as Multicast Listener Discovery [RFC5790].
Similarly, a group can identify a set of services on one device. For Similarly, a group can identify a set of resources of one server.
examples a device contains four I/O channels. The device hosts one For examples a device contains four I/O channels. The device hosts
server which provides four services to access each of the four one server with four resources to access each of the four individual
individual channels separately. Commonly, it is also required to channels separately. Commonly, it is also required to access all
access a subset of all four channels simultaneously. An additional four channels as one group. An additional path identifies the group
path identifies the group of services. An example set of services of services. An example set of services and service-group is:
and service-group becomes:
URI path Targeted group URI path Targeted group
/IOchannel/channel1... "channel 1 of the IO channel device " /IOchannel/1... "channel 1 of the IO channel device "
/IOchannel/channel2... "channel 2 of the IO channel device " /IOchannel/2... "channel 2 of the IO channel device "
/IOchannel/channel3... "channel 3 of the IO channel device " /IOchannel/3... "channel 3 of the IO channel device "
/IOchannel/channel4... "channel 4 of the IO channel device " /IOchannel/4... "channel 4 of the IO channel device "
/IOchannel/group1-3... "channel 1 to 3 of the IO channel device " /IOchannel/... "channel 1 to 4 of the IO channel device "
A group defines a set of servers or a set of service attributes. A group defines a set of servers possibly containing a set of
Grouping of the service attributes is provided by the device resources. Grouping of the resources is provided by the device
manufacturer. Grouping of the services is supported by DNS and manufacturer. Grouping of the servers is supported by DNS and
multicast protocols. The multicast address(es) identify the servers multicast protocols. The multicast address(es) identify the servers
belonging to the group. A given server might belong to a number of belonging to the group. A given server might belong to a number of
groups. For example the server belonging to the "blue-lights" group groups. For example the server belonging to the "blue-lights" group
in a given corridor might also belong to the groups: "whole in a given corridor might also belong to the groups: "whole
building", "given wing", "given floor", "given corridor", and "lights building", "given wing", "given floor", "given corridor", and "lights
in given corridor". From the perspective of a server, the main in given corridor". From the perspective of a server, the main
consequence of joining a group is it should accept packets for an consequence of joining a group is it should accept packets for an
additional IP address. The granularity of the domain names may have additional IP address. The granularity of the domain names may have
an impact on the complexity of the DNS infrastructure but not an impact on the complexity of the DNS infrastructure but not
necessarily on the low-resource destinations or sources. Assuming necessarily on the low-resource destinations or sources. Assuming
skipping to change at page 12, line 40 skipping to change at page 12, line 33
These goals are necessary to support the operation of commercial These goals are necessary to support the operation of commercial
building control. Returning the instances results in a list of building control. Returning the instances results in a list of
names. For building control these names can be any sequence of names. For building control these names can be any sequence of
characters as long as for each service instance these names are characters as long as for each service instance these names are
unique within the domain. In [I-D.cheshire-dnsext-dns-sd] the office unique within the domain. In [I-D.cheshire-dnsext-dns-sd] the office
equipment in the IT domain is recommended to use understandable and equipment in the IT domain is recommended to use understandable and
human-readable names. The Home domain may have a need for human human-readable names. The Home domain may have a need for human
understandable names. This is not the case for the commercial understandable names. This is not the case for the commercial
building automation domain. However, uniqueness of the name is building automation domain. However, uniqueness of the name is
necessary for the application that needs to address the service necessary for the application that needs to address the service in a
interface on the devices in a consistent manner. Given the large consistent manner. Given the large number of devices in a building
number of devices in a building (several hundreds to thousands) (several hundreds to thousands) scaling is an important aspect of the
scaling is an important aspect of the service discovery. A set of service discovery. A set of central DNS servers will provide the
central DNS servers will provide the scalability. The expectation is scalability. The expectation is that names need to be managed
that names need to be managed consistently by a central authority consistently by a central authority which can be supported by the DNS
which can be supported by the DNS server. Tools will assist the server. Tools will assist the installer and operator of the network
installer and operator of the network to do the installation, to do the installation, configuration and maintenance of the network
configuration and maintenance of the network structure. Small structure. Small devices will use the DNS server to learn the
devices will use the DNS server to learn the communication partners communication partners providing a given service within their domain
providing a given service within their domain and to resolve the IP and to resolve the IP addresses of the communication partners.
addresses of the communication partners.
Within the home it is more important that the names convey the Within the home it is more important that the names convey the
purpose of the service to the user reading the names and selecting purpose of the service to the user reading the names and selecting
his favored service instance. Non-unique names, although confusing, his favored service instance. Non-unique names, although confusing,
can probably be handled by the user of these names. Scalability is can probably be handled by the user of these names. Scalability is
less of an issue because a smaller number of devices is implicated. less of an issue because a smaller number of devices is implicated.
The network in the home is probably more dynamic than its commercial The network in the home is probably more dynamic than its commercial
counter-part, with many movements of devices and arrival or removal counter-part, with many movements of devices and arrival or removal
of devices. of devices.
skipping to change at page 13, line 30 skipping to change at page 13, line 21
DNS-Based Service Discovery (DNS-SD) defines a conventional way to DNS-Based Service Discovery (DNS-SD) defines a conventional way to
configure DNS PTR, SRV, and TXT records to facilitate discovery of configure DNS PTR, SRV, and TXT records to facilitate discovery of
services within a subdomain, re-using the existing DNS services within a subdomain, re-using the existing DNS
infrastructure. This section gives a cursory overview of DNS-SD; see infrastructure. This section gives a cursory overview of DNS-SD; see
[I-D.cheshire-dnsext-dns-sd] for a complete description. [I-D.cheshire-dnsext-dns-sd] for a complete description.
A DNS-SD service instance name is of the form A DNS-SD service instance name is of the form
<Instance>.<ServiceType>.<Location>. <Instance>.<ServiceType>.<Location>.
The Location part of the service name is identical to the global (DNS The Location part of the service name is identical to the DNS
subdomain) part of the authority in URIs that identify the resources subdomain part of the authority in URIs that identify the resources
on this device or group and may identify a building zone as in the of this server or group and may identify a building zone as in the
examples above. examples above.
The ServiceType is composed of multiple parts: 1) the IP protocol The ServiceType SHOULD have the form [_subtype._sub.]_type._proto
part, 2) the application or service type of the defining organization (e.g. _temp._sub._bc._udp). The _proto identifier provides a
(e.g. ZigBee HomeAutomation), and optionally 3) the subtype of the
service (e.g. temperature sensor). The ServiceType SHOULD have the
form [_subtype._sub.]_type._proto. The _proto identifier provides a
transport protocol hint as required by the SRV record definition transport protocol hint as required by the SRV record definition
[RFC2782] and, in the case of CoAP, it is always "_udp". The _type [RFC2782] and, in the case of CoAP, it is always "_udp". The _type
identifier is determined by standards development organization (SDO) identifier is determined by standards development organization (SDO)
and MUST be registered with dns-sd.org [dns-sd]. The SDO is then and MUST be registered with dns-sd.org [dns-sd] (e.g. _bc for
free to specifiy one or more _subtype identifiers, which must be building control). The SDO is then free to specifiy one or more
unique for a given _type. The _subtype and _type labels are _subtype identifiers, which must be unique for a given _type (e.g.
separated by the literal "._sub" label. _temp). The _subtype and _type labels are separated by the literal
"._sub" label.The maximum length of the type and subtype fields is 14
A PTR record with the label "_type._proto" is defined for each end- octets, but shorter names are encouraged to reduce packet sizes.
point in a selected domain, and this record's value is set to the
service instance name (which in turn identifies the SRV and TXT
records for the CoAP end-point). Assuming that the DALI organization
defines _type as "dali" and _proto as "udp" for its CoAP binding, PTR
records with the label "_dali._udp" are stored in DNS-SD. Assuming
ZigBee HomeAutomation defines _type as "HomeAutomation", PTR records
with label "_HomeAutomation._udp" are stored. This approach permits
DNS-SD to return all services pertaining to HomeAutomation or DALI.
DNS-SD also supports one level of subtype, which can be used to A PTR record with the label "_type._proto" is defined for each server
locate services based on the object model (schema) of a given in a selected domain, and this record's value is set to the service
standard. [I-D.cheshire-dnsext-dns-sd] suggests to separate the instance name (which in turn identifies the SRV and TXT records for
subtype from the service by _sub. For example: _AI._sub._bacnet._udp the CoAP server).
for an Analog Input object of BACnet or _lamp._sub._dali._udp for a
lamp type of DALI. The maximum length of the type and subtype fields
is 14 octets, but shorter names are encouraged to reduce packet
sizes.
The Instance part of the service name may be changed during the The Instance part of the service name may be changed during the
commissioning process. It must be unique for a given ServiceType commissioning process. It must be unique for a given ServiceType
within the subdomain. The complete service name uniquely identifies within the subdomain. The complete service name uniquely identifies
an SRV and a TXT record in the DNS zone. The granularity of a an SRV and a TXT record in the DNS zone. The granularity of a
service name MAY be at the group or server level, or it could service name MAY be at the group or server level, or it could
represent a particular resource (service interface) within a CoAP represent a particular resource within a CoAP server. The SRV record
device. The SRV record contains the host (AAAA record) name and port contains the host (AAAA record) name and port of the service. The
of the service. In the case where a service name identifies a path part of the URI MUST be placed in the TXT record (path=) when
particular functional entry point, the path part of the URI MUST be multiple resources belong to the same service.
placed in the TXT record (PATH=).
4.3. Service vs Host Names
In general, the authority "www.example.com" does not refer to a
canonical host name (the label of a AAAA record). Logically, it
refers to the "world wide web service" for the example.com domain.
Literally, the "www" is probably the label of a CNAME record that
names a AAAA record that may in turn specify more than one address
(in the case of round-robin load leveling between identical origin
server instances).
The SRV record functions something like the CNAME in this case,
except that it is capable of resolving to a canonical host name plus
a listening socket. An optional TXT record may be configured with
the same name as the SRV record and be used to store context-
dependent key=value pairs. For example, a multi-function device
might define a service name for each "base URI" that locates a
service interface (e.g. abs-path=/.well-known/zigbee/sensor/). Thus,
the URI coap://host.example.com/temp might resolve through DNS-SD
lookups to coap://[fdfd::1234]/.well-known/zigbee/sensor/temp.
TODO: Kerry: this last line needs quite some explanations !!!!
4.4. Browsing for Services 4.3. Browsing for Services
Devices in a given Location with given ServiceType, _type._proto, may Devices in a given Location with given ServiceType, _type._proto, may
be enumerated by sending a DNS query for PTR records named be enumerated by sending a DNS query for PTR records named
_type._proto to the authoritative server for that zone associated _type._proto to the authoritative server for that zone associated
with the Location. A list of names for SRV records matching that with the Location. A list of instance names for SRV records matching
ServiceType.Location is returned. Each SRV record contains the host that <ServiceType>.<Location> is returned. Each SRV record contains
name and port of a CoAP server. The IP address of the device is the host name and port of a CoAP server. The IP address of the
obtained by resolving the host name. DNS-SD also specifies an device is obtained by resolving the host name. DNS-SD also specifies
optional TXT record, having the same name as the SRV record, which an optional TXT record, having the same name as the SRV record, which
can contain "key=value" attributes. Apart from defining standardized can contain "key=value" attributes. Apart from defining standardized
resources identified by IF=XXX, the XXX organization may also define resources identified by if=XXX, the XXX organization may also define
the standard "key=value" pairs present in the TXT record, e.g. the standard "key=value" pairs present in the TXT record, e.g.
type=switch. By convention, the first pair is txtver=<number> so type=switch. By convention, the first pair is txtver=<number> so
that different versions of the XXX schema may interoperate. For that different versions of the XXX schema may interoperate. For
example: A query is sent to DNS-SD to return all DALI lamps within example: A query is sent to DNS-SD to return all DALI lamps within
the domain office5/mybuilding and with ServiceType: the domain office5/mybuilding and with ServiceType:
_lamp._sub._dali._udp. DNS-SD returns the list of all SRV records _lamp._sub._dali._udp. DNS-SD returns the list of all SRV records
and AAAA records of the devices within the domain providing the and AAAA records of the devices within the domain providing the
wanted service. wanted service.
4.5. Resource vs Service Discovery 4.4. Resource vs Service Discovery
Service discovery is concerned with finding the IP address, port, Service discovery is concerned with finding the IP address, port,
protocol, and possibly path of a named service. Resource discovery protocol, and possibly path of a named service. Resource discovery
is a fine-grained enumeration of resources (path-names) within a is a fine-grained enumeration of resources (path-names) of a server.
service. [I-D.ietf-core-link-format] specifies a resource discovery [I-D.ietf-core-link-format] specifies a resource discovery pattern,
pattern, such that sending a confirmable GET message for the /.well- such that sending a confirmable GET message for the /.well-known/core
known/core resource returns a set of links available from the server. resource returns a set of links available from the server. These
These links may describe resources hosted on that server or on other links describe resources hosted on that server.
servers.
Assuming the ability to multicast the GET over the site link, CoAP CoAP link format can be used to enumerate attributes and populate the
resource discovery can be used to enumerate attributes and populate DNS-SD database in a semi-automated fashion. CoAP resource
the DNS-SD database in a semi-automated fashion. CoAP resource
descriptions can be imported into DNS-SD for exposure to service descriptions can be imported into DNS-SD for exposure to service
discovery by using /.well-known/core attributes as the basis for a discovery as described in [I-D.lynn-core-discovery-mapping]. The
unique "Instance" name, and the ServiceType, while using some means values stored in the DNS-SD directory are extracted from the
to establish in which subdomain the service should be registered information stored in the resource directory associated with a set of
CoAP hosts [I-D.shelby-core-resource-directory]. The resources
(TBD). describe how the services can be manipulated in detail and in
concreto.
The DNS TXT record can be populated by importing the other resource
description attributes as they share the same key=value format
specified in Section 6 of [I-D.cheshire-dnsext-dns-sd]. The values
stored in the DNS-SD directory are extracted from the information
stored in the resource directory associated with a set of CoAP hosts
[I-D.shelby-core-resource-directory]. The resources describe how the
services can be manipulated in detail and in concreto.
It is assumed that a resource directory exists per 6LoWPAN [RFC4944], It is assumed that a resource directory exists per 6LoWPAN [RFC4944],
possibly running on the edge router. The DNS-SD provides a larger possibly running on the edge router. The DNS-SD provides a larger
scope by storing the info of all services over a set of scope by storing the info of all services over a set of
interconnected 6LoWPANs. Where the resource directory is possibly interconnected 6LoWPANs. Where the resource directory is possibly
completely adequate for home networks, handling of multiple resource completely adequate for home networks, handling of multiple resource
directories can be quite cumbersome for the many 6LoWPANs envisaged directories can be quite cumbersome for the many 6LoWPANs envisaged
for offices. However, during network configuration, the resource for offices. However, during network configuration, the resource
directory can be used as long as the DNS is not yet accessible. directory can be used as long as the DNS is not yet accessible.
The DNS-SD approach is complementary to the more fine-grained The DNS-SD approach is complementary to the more fine-grained
resource discovery, fits better the concept of discovering devices resource discovery, fits better the concept of service by discovering
with given properties (services). DNS-SD supports a hierarchical servers with given properties. DNS-SD supports a hierarchical
approach to the naming of the services as discussed in section 3. approach to the naming of the services as discussed in section 3.
DNS-SD provides a directory structure that scales well with the DNS-SD provides a directory structure that scales well with the
network size as shown by its present-day operation. network size as shown by its present-day operation.
5. DNS record structure 5. DNS record structure
An example is presented which explains the Resource Record (RR) An example is presented which explains the Resource Record (RR)
structure on the DNS server. This section follows the mapping structure on the DNS server. This section follows the mapping
specified in [I-D.lynn-core-discovery-mapping], which defines how to specified in [I-D.lynn-core-discovery-mapping], which defines how to
fill the DNS-SD records from the link extension values. Suppose the fill the DNS-SD records from the link extension values. Suppose the
services are delivered by ZigBee home automation devices. The services are delivered by XXX building control devices. The example
example subtype- and context- names are assumed to be standardized by subtype- and context- names are assumed to be standardized by the XXX
the ZigBee alliance. All devices are situated in one office with alliance. All devices are situated in one office with location
location office4.bldg8.example.com. The names in the examples are office4.bldg8.example.com. The names in the examples are more
more verbose than recommended to make the examples more readable. verbose than recommended to make the examples more readable. The
The table presents the services provided in the office control table presents the services provided in the office control network:
network:
service ServiceType Number service ServiceType Number
illumination _OnOff_light._sub._HomeAutomation._udp 4 illumination _OnOff_light._sub._bc._udp 4
presence _occup_sensor._sub._HomeAutomation._udp 1 presence _occup_sensor._sub._bc._udp 1
temperature _temp_sensor._sub._HomeAutomation._udp 1 temperature _temp_sensor._sub._bc._udp 1
shading _shade_control._sub._HomeAutomation._udp 1 shading _shade_control._sub._bc._udp 1
For every service there is a PTR record stored, with as label the In DNS PTR records with as label the ServiceType have as value
ServiceType, that points to the service instances. The unique service instance names. The unique Instance names identify the
Instance names identify the service instances. The unique names are service instances. In the example, the names contain id-x, with x in
represented as id-x, with x in natural numbers. They are usually natural numbers. The names are usually created at the factory floor
created at the factory floor and somehow attached to the product. and somehow attached to the product. The ServiceTypes have been
The ServiceTypes have been suffixed with .04.8 to represent office4 suffixed with .04.b8 to represent office4 in building8. The same
in building8. suffix is used as PTR label to enemerate all instance of a given
service, or within a given domain.
_OnOff_light._sub._HomeAutomation._udp.04.8 PTR id-1._OnOff_light _OnOff_light._sub._bc._udp.04.b8 PTR id-1._OnOff_light
_OnOff_light._sub._HomeAutomation._udp.04.b8 PTR id-2._OnOff_light bc._udp.04.b8 PTR id-1._OnOff_light
_OnOff_light._sub._HomeAutomation._udp.04.b8 PTR id-3._OnOff_light 04.b8 PTR id-1._OnOff_light
_OnOff_light._sub._HomeAutomation._udp.04.b8 PTR id-4._OnOff_light _OnOff_light._sub._bc._udp.04.b8 PTR id-2._OnOff_light
_occup_sensor._sub._HomeAutomation._udp.04.b8 PTR id-5._occup_sensor bc._udp.04.b8 PTR id-2._OnOff_light
_temp_sensor._sub._HomeAutomation._udp.04.b8 PTR id-6._temp_sensor 04.b8 PTR id-2._OnOff_light
_shade_control._sub._HomeAutomation._udp.04.b8 PTR id-7._temp_sensor _OnOff_light._sub._bc._udp.04.b8 PTR id-3._OnOff_light
bc._udp.04.b8 PTR id-3._OnOff_light
04.b8 PTR id-3._OnOff_light
_OnOff_light._sub._bc._udp.04.b8 PTR id-4._OnOff_light
bc._udp.04.b8 PTR id-4._OnOff_light
04.b8 PTR id-4._OnOff_light
_occup_sensor._sub._bc._udp.04.b8 PTR id-5._occup_sensor
bc._udp.04.b8 PTR id-5._occup_sensor
04.b8 PTR id-5._occup_sensor
_temp_sensor._sub._bc._udp.04.b8 PTR id-6._temp_sensor
bc._udp.04.b8 PTR id-6._temp_sensor
04.b8 PTR id-6._temp_sensor
_shade_control._sub._bc._udp.04.b8 PTR id-7._temp_sensor
bc._udp.04.b8 PTR id-7._temp_sensor
04.b8 PTR id-7._temp_sensor
In the above example the id-x identifiers without the subtype suffix In the above example the id-x identifiers without the subtype suffix
would be discriminating enough. would be discriminating enough.
Discovery can be done with the following results. A query with the Discovery can be done with the following results. A query with the
following argument returns following argument returns
query argument result list query argument result list
.04.8 id-1._OnOff_light .04.8 id-1._OnOff_light
....... .......
id-7._temp_sensor id-7._temp_sensor
_HomeAutomation._udp.04.b8 id-1._OnOff_light _bc._udp.04.b8 id-1._OnOff_light
....... .......
id-7._temp_sensor id-7._temp_sensor
_OnOff_light._sub._HomeAutomation._udp.04.b8 id-1._OnOff_light _OnOff_light._sub._bc._udp.04.b8 id-1._OnOff_light
....... .......
id-4._OnOff_light id-4._OnOff_light
_occup_sensor._sub._HomeAutomation._udp.04.b8 id-5._occup_sensor _occup_sensor._sub._bc._udp.04.b8 id-5._occup_sensor
When other offices are included in the database, the query argument When other offices are included in the database, the query argument
04.b8 selects those entries which are associated with office4 in 04.b8 selects those entries which are associated with office4 in
building8 and rejects any others. The example shows clearly the building8 and rejects any others. The example shows clearly the
query granularity that can be obtained and the care that must be query granularity that can be obtained and the care that must be
exercised when defining the names of the ServiceTypes. exercised when defining the names of the ServiceTypes.
The unique identifiers suffixed with their subtype are the labels of The service instances (value of PTR records) are the labels of the
the SRV, AAAA and TXT records describing the service instance. The SRV, AAAA and TXT records describing the service instance. The SRV
SRV record specifies the location (authority) and the port number. record specifies the location (authority) and the port number. In
In the authority o4.b8 refers to office4 in building8. The AAAA the authority o4.b8 refers to office4 in building8. The AAAA record
record specifies the IP-address, while the TXT record specifies the specifies the IP-address, while the TXT record specifies the subtype
subtype and the data representation of the legacy parser (IF = and the data representation of the legacy parser (if = ZigBee).
ZigBee).
id-1._OnOff_light SRV light1.o4.b8.example.com Port-x id-1._OnOff_light SRV light1.o4.b8.example.com Port-x
AAAA FDFD::1234 AAAA fdfd::1234
TXT IF=ZigBee TXT if=ZigBee
id-2._OnOff_light SRV light2.o4.b8.example.com Port-x id-2._OnOff_light SRV light2.o4.b8.example.com Port-x
AAAA FDFD::1235 AAAA fdfd::1235
TXT IF=ZigBee TXT if=ZigBee
id-3._OnOff_light SRV light3.o4.b8.example.com Port-x id-3._OnOff_light SRV light3.o4.b8.example.com Port-x
AAAA FDFD::1236 AAAA fdfd::1236
TXT IF=ZigBee TXT if=ZigBee
id-4._OnOff_light SRV light4.o4.b8.example.com Port-x id-4._OnOff_light SRV light4.o4.b8.example.com Port-x
AAAA FDFD::1237 AAAA fdfd::1237
TXT IF=ZigBee TXT if=ZigBee
id-5._occup_sensor SRV occup.o4.b8.example.com Port-x id-5._occup_sensor SRV occup.o4.b8.example.com Port-x
AAAA FDFD::1238 AAAA fdfd::1238
TXT IF=ZigBee TXT if=ZigBee
id-6._temp_sensor SRV temp.o4.b8.example.com Port-x id-6._temp_sensor SRV temp.o4.b8.example.com Port-x
AAAA FDFD::1239 AAAA fdfd::1239
TXT IF=ZigBee TXT if=ZigBee
id-7._shade_control SRV shade.o4.b8.example.com Port-x id-7._shade_control SRV shade.o4.b8.example.com Port-x
AAAA FDFD::1240 AAAA fdfd::1240
TXT IF=ZigBee TXT if=ZigBee
It is possible that the temperature sensor and occupancy sensor are It is possible that the temperature sensor and occupancy sensor are
delivered on one device. The consequence is that one device hosts delivered on one device. The consequence is that one device hosts
two services. In the DNS table the four lights and the shade two services. In the DNS table the four lights and the shade
controller are unaffected. However, the PTR records with the controller are unaffected. However, the PTR records with the
occupancy and temperature sensor point to the same unique identifier occupancy and temperature sensor point to the same unique identifier
id-8 that is suffixed with the name of the subtype. This example id-8 that is suffixed with the name of the subtype. This example
shows that the subtype suffix is needed to discriminate between the shows that the subtype suffix is needed to discriminate between the
two services. two service instances.
_occup_sensor._sub._HomeAutomation._udp PTR id-8._occup_sensor _occup_sensor._sub._bc._udp PTR id-8._occup_sensor
_temp_sensor._sub._HomeAutomation._udp PTR id-8._temp_sensor _temp_sensor._sub._bc._udp PTR id-8._temp_sensor
Two SRV records with accompanying AAAA and TXT records describe the Two SRV records with accompanying AAAA and TXT records describe the
two servers, each providing one service, in more detail. The servers two servers, each providing one service, in more detail. The servers
share the same IP address but are connected to different ports, and share the same IP address but are connected to different ports, and
do have a different paths names. The TXT record is used to specify do have a different paths names. The TXT record is used to specify
the path part with "PATH=". the path part with "path=".
id-8._occup_sensor SRV occup.o4.b8.example.com Port-x id-8._occup_sensor SRV occup.o4.b8.example.com Port-x
AAAA FDFD::1241 AAAA fdfd::1241
TXT PATH=/os IF=ZigBee TXT path=/os if=ZigBee
id-8._temp_sensor SRV temp.o4.b8.example.com Port-y id-8._temp_sensor SRV temp.o4.b8.example.com Port-y
AAAA FDFD::1241 AAAA fdfd::1241
TXT PATH=/ts IF=ZigBee TXT path=/ts if=ZigBee
The path names /ts and /os are short names for temperature_sensor and The path names /ts and /os are short names for temperature_sensor and
occupancy_sensor respectively. Not all multi-function devices will occupancy_sensor respectively. Not all multi-function devices will
use different ports for the individual functions. It is also quite use different ports for the individual functions. It is also quite
common to use different IP interfaces with different IP addresses, common to use different IP interfaces with different IP addresses,
reflected by the value of the AAAA records. reflected by the value of the AAAA records.
5.1. DNS group example 5.1. DNS group example
Another aspect is the grouping of servers. Where in the former Another aspect is the grouping of servers. Where in the former
section the names of the services are standardized names, this is section the names of the services are standardized names, this is
less probable for the group names. Usually the group names are less probable for the group names. Usually the group names are
application specific or are standardized at the manufacturer. For application specific or are standardized at the manufacturer. For
example, assume that a group all-light.o4.b8.example.com is created example, assume that a group all-light.o4.b8.example.com is created
which contains all four lights inside office4. The accompanying which contains all four lights inside office4. The accompanying
ServiceType can be defined as _all_light._sub._HomeAutomation._udp. ServiceType can be defined as _all_light._sub._bc._udp. The
The use of HomeAutomation is taken although _all_light is not a ServiceType suffixed with 04.b8 points to a unique identifier defined
supported service within HomeAutomation profile. The ServiceType as _all_light.04.b8, assuming that this is the only _all_light group
suffixed with 04.b8 points to a unique identifier defined as
_all_light.04.b8, assuming that this is the only _all_light group
within office 4 of building 8. The PTR record looks like: within office 4 of building 8. The PTR record looks like:
_all_light._sub._HomeAutomation._udp.04.b8 PTR _all_light.04.b8 _all_light._sub._bc._udp.04.b8 PTR _all_light.04.b8
It is assumed that the group all_light.o4.b8.example.com has received It is assumed that the group all_light.o4.b8.example.com has received
a multicast address: FF1E::148. The accompanying SRV, AAAA, and TXT a multicast address: ff1e::148. The accompanying SRV, AAAA, and TXT
RR become: RR become:
_all_light.04.b8 SRV all_light.o4.b8.example.com Port-z _all_light.04.b8 SRV all_light.o4.b8.example.com Port-z
AAAA FF1E::148 AAAA ff1e::148
TXT IF=ZigBee TXT if=ZigBee
In some cases it may be desirable to show all hosts which are part of When a multicast message is sent to a group, the path of the accessed
the multicast group. This can be done using the PTR records which resource must be strictly the same for all servers. The naming of
point to the authorities of the associated hosts. The AAAA records the path is typically a responsibility for the standardisation
provide the IP addresses of the hosts. organisations describing the command set for a given application
area. However a constraint exits in the case of mult-function
devices which host multiple resource of the same type. For example a
device with three lamps with corresponding onoff attributes can be
accessed via the three different paths:
all_light.o4.b8.example.com PTR light1.o4.b8.example.com /light/1/onoff
all_light.o4.b8.example.com PTR light2.o4.b8.example.com /light/2/onoff
all_light.o4.b8.example.com PTR light3.o4.b8.example.com /light/3/onoff
all_light.o4.b8.example.com PTR light4.o4.b8.example.com
light1.o4.b8.example.com AAAA FDFD::1234 A unique path to the onoff resource of all instances of light on this
light2.o4.b8.example.com AAAA FDFD::1235 device can be provided by /light/onoff. As this is logically the
light3.o4.b8.example.com AAAA FDFD::1236 path to a single instance on a mono-function device. The
light4.o4.b8.example.com AAAA FDFD::1237 corresponding unique paths for onoff to be used in the multicast
message becomes /light/onoff. The corresponding resource records for
a luminaire, named lm1, in DNS become:
_light._sub._bc._udp.04.b8 PTR _all_light.04.b8
_light._sub._bc._udp.04.b8 PTR _light_1.04.b8
_light._sub._bc._udp.04.b8 PTR _light_2.04.b8
_light._sub._bc._udp.04.b8 PTR _light_3.04.b8
_all_light.04.b8 SRV all_light.o4.b8.example.com Port-x
AAAA ff1e::148
TXT if=ZigBee path=/light
_light_1.04.b8 SRV lm1.o4.b8.example.com Port-z
AAAA fdfd::1234
TXT if=ZigBee path=/light/1
_light_2.04.b8 SRV lm1.o4.b8.example.com Port-z
AAAA fdfd::1234
TXT if=ZigBee path=/light/2
_light_3.04.b8 SRV lm1.o4.b8.example.com Port-z
AAAA fdfd::1234
TXT if=ZigBee path=/light/3
The entries in DNS can be used to form groups with the light weight The entries in DNS can be used to form groups with the light weight
group management protocol and multicast listener discovery [RFC5790]. group management protocol and multicast listener discovery [RFC5790].
In contrast to the earlier examples the name of the PTR record is a
domain name and not a ServiceType.
5.2. Operational use of DNS-SD 5.2. Operational use of DNS-SD
The populated DNS-SD server provides the necessary support for the The populated DNS-SD server provides the necessary support for the
applications to execute their control loops with minimum operator applications to execute their control loops with minimum operator
support. The operation of the office network can be split up in support. The operation of the office network can be split up in
phases. In a first phase the network is commissioned, such that a phases. In a first phase the network is commissioned, such that a
relation is established between the IP address, the servicetype and relation is established between the IP address, the servicetype and
the domain. The servicetype can be extracted from the link-format as the domain. The servicetype can be extracted from the link-format as
described in [I-D.shelby-core-resource-directory]. After described in [I-D.shelby-core-resource-directory]. After
skipping to change at page 20, line 37 skipping to change at page 20, line 20
[I-D.lynn-dnsext-site-mdns] when appropriate. In the second phase [I-D.lynn-dnsext-site-mdns] when appropriate. In the second phase
remote controllers or other hand-held devices can be used to discover remote controllers or other hand-held devices can be used to discover
the services of a given type, to group the services, and to store the the services of a given type, to group the services, and to store the
group names into DNS-SD or xmDNS as appropriate. Pointing out the group names into DNS-SD or xmDNS as appropriate. Pointing out the
members of a group can be in any kind of manner from typing members members of a group can be in any kind of manner from typing members
in, selecting them from a browser list, etc. in, selecting them from a browser list, etc.
5.3. Commissioning CoAP devices 5.3. Commissioning CoAP devices
For clarity it is assumed in this section that a device hosts one For clarity it is assumed in this section that a device hosts one
server. The URI of the device together with its service completely server. A device has received a unique device identifier at the
determines the function of the device within the building. The production plant. Given the authority naming presented in section
authority part of the URI represents the location of the host within 2.2 the authority name represents the location of the host within the
the domain name space. Given the authority naming presented in building.
section 2.2 the authority name represents the location of the host
within the building.
Commissioning means the following three actions: Commissioning means the following three actions:
- Defining the URI (location) - Defining the URI (location)
- Assigning an IP address to the URI - Assigning an IP address to the URI
- mapping the unique device identifier to the URI - mapping the unique device identifier to the URI
Two cases of the office network are considered for commissioning: (1) Two cases of the office network are considered for commissioning: (1)
no 6LBR and no DNS server connected, and (2) a 6LBR connects the no 6LBR and no DNS server connected, and (2) a 6LBR connects the
office network to a DNS server. office network to a DNS server.
When an architect has designed the building and described all light When an architect has designed the building and described all light
points, ventilators, heating- and cooling units, and sensors, it is points, ventilators, heating- and cooling units, and sensors, it is
necessary to identify all these devices spatially and functionally. necessary to identify all these devices spatially and functionally.
Storing the triple Instance.ServiceType.Location into DNS-SD Storing the triple <Instance>.<ServiceType>.<Location> into DNS-SD
represents the commissioning process. The Instance is the unique represents the commissioning process. The Instance is the unique
identifier given to the device in the factory but which has no identifier given to the device in the factory but which has no
relation to its later location. The ServiceType together with the relation to its later location. The ServiceType together with the
Location fully determine the semantics of the data returned by the Location represent the spatial and functional aspects of the device
device. as specified by the architect.
Design decision: A commissioning tool with access to the network is Design decision: A commissioning tool with access to the network is
used for the commissioning phase. used for the commissioning phase.
For example, dependent on used technology and production process, the For example, dependent on used technology and production process, the
following situation (state) exists in a host after physical following situation (state) may exist in a host after physical
installation of the devices: installation of the devices and before commissioning:
- A given host is unaware of its Location. - A given host is unaware of its Location.
- A given host knows its ServiceType and Instance. The Instance is - A given host knows its ServiceType and Instance. The Instance is
also readable by bar code reader. also readable by bar code reader.
- The commissioning tool knows all Locations to which hosts need to - The commissioning tool knows all Locations to which hosts need to
be assigned. be assigned.
- A DHCP server (neighbor discovery) provided each host with a - Each host has a (site-local) IP address.
(site-local) IP address.
Consider the commissioning process (1) with a central DNS-SD server Consider the commissioning process (1) with a central DNS-SD server
and (2) without a central server using xmDNS. The commissioning and (2) without a central server using xmDNS. The commissioning
processes described below are just examples and should not be taken processes described below are just examples and should not be taken
as working procedures for commissioning devices in a building. as working procedures for commissioning devices in a building.
5.3.1. DNS-SD server present 5.3.1. DNS-SD server present
The installer reads with a bar code reader, attached to the The installer reads with a bar code reader, attached to the
commissioning tool, the identifier of the device to commission. It commissioning tool, the identifier of the device to commission. It
is assumed that the tool can learn the IP address of the device with is assumed that the tool can learn the IP address of the device with
the given identifier. The tool displays on a screen the physical the given identifier. The tool displays on a screen the physical
lay-out of the devices within the building. The installer selects, lay-out of the devices within the building. The installer selects,
on the screen of the tool, the physical location of the chosen on the screen of the tool, the physical location of the chosen
device. From the designated physical location the tool creates the device. From the designated physical location the tool creates the
URI of the selected device. The tool inserts the URI and the IP URI of the selected device. The tool inserts the URI and the IP
address into the DNS server. For example the light with URI address into the DNS server. For example the light with URI
light1.o4.b8.example.com is represented with an AAAA record: light1.o4.b8.example.com is represented with an AAAA record:
light1.o4.b8.example.com AAAA FDFD::1234 light1.o4.b8.example.com AAAA fdfd::1234
The tool reads the service name and type from the device using The tool reads the service name and type from the device using
resource information stored according to the link-format resource information stored according to the link-format
[I-D.ietf-core-link-format]. With this information the tool [I-D.ietf-core-link-format]. With this information the tool
constructs the PTR, SRV and TXT records according to the example constructs the PTR, SRV and TXT records according to the example
presented in section 5. presented in section 5.
This is done for all devices within a given part of the building. This is done for all devices within a given part of the building.
After the commissioning process, all resources of each device have an After the commissioning process, all resources of each device have an
URI and IP address which are stored in the central DNS-SD server. URI and IP address which are stored in the central DNS-SD server.
When devices are restarted, the DHCP server allocates IP addresses to When devices are restarted, the DHCP server may allocate new IP
the device and updates the DNS server. addresses to the device and update the DNS server.
5.3.2. DNS-SD server not present 5.3.2. DNS-SD server not present
It is assumed that the building network is composed of independent It is assumed that the building network is composed of independent
network segments (possibly a single site) such that each device on a network segments (possibly a single site) such that each device on a
given segment can communicate directly with any other device on this given segment can communicate directly with any other device on this
segment. The segments are not connected to a 6LBR and have no access segment. The segments are not connected to a 6LBR and have no access
to DNS or other servers. The installer knows these segments and has to DNS or other servers. The installer knows these segments and has
a list of devices for a given segment. In the tool the installer a list of devices for a given segment. In the tool the installer
selects the names which belong to the given building segment. The selects the names which belong to the given building segment. The
skipping to change at page 23, line 8 skipping to change at page 22, line 36
Proxies will be used in CoAP networks for at least two major reasons: Proxies will be used in CoAP networks for at least two major reasons:
(1) http/coap proxy, and (2) proxy of service on battery-less device. (1) http/coap proxy, and (2) proxy of service on battery-less device.
The first proxy is probably implemented as forward proxy, while the The first proxy is probably implemented as forward proxy, while the
latter is probably implemented as backward proxy. The battery-less latter is probably implemented as backward proxy. The battery-less
device will at rare occasions (when it is not sleeping) and during device will at rare occasions (when it is not sleeping) and during
installation answer the GET /.well-known/core request. The return installation answer the GET /.well-known/core request. The return
data are used by the installation tool to make the proxy device data are used by the installation tool to make the proxy device
return the same resource names on /.well-known/core as is returned by return the same resource names on /.well-known/core as is returned by
the sleeping device. An installation tool installs on the proxy all the sleeping device. An installation tool installs on the proxy all
the resources of the sleeping device for which the proxy is assumed the resources of the sleeping device for which the proxy is assumed
to answer. Each resource on the proxy is informed of the service to answer. Consequently, the proxy is discovered as a multi-server
name of the sleeping device by the installation tool. Consequently, host with as many path names as it proxies sleeping servers. The
the proxy is discovered as a multi-service host with as many path servers on sleeping devices should not be discoverable via DNS-SD.
names as it proxies sleeping services. The services of the sleeping However, AAAA records are generated for the sleeping device host
devices should not be discoverable via DNS-SD. However, AAAA records name. This host name is used by the proxy to subscribe to the
are generated for the sleeping device host name. This host name is "sporadic" services of the sleeping device. For example assume two
used by the proxy to subscribe to the services of the sleeping sleeping devices, an occupancy sensor and a temperature sensor, and
device. For example assume two sleeping devices, an occupancy sensor one proxy. Two service types are defined with PTR records in DNS-SD.
and a temperature sensor, and one proxy. Two service types are The identifier id-1 of the proxy is used by the installation tool to
defined with PTR records in DNS-SD. The identifier id-1 of the proxy define the Instances.
is used by the installation tool to define the Instances.
_occup_sensor._sub._HomeAutomation._udp.04.b8 PTR id-1._occup_sensor _occup_sensor._sub._bc._udp.04.b8 PTR id-1._occup_sensor
_temp_sensor._sub._HomeAutomation._udp.04.b8 PTR id-1._temp_sensor _temp_sensor._sub._bc._udp.04.b8 PTR id-1._temp_sensor
Two SRV records with accompanying AAAA and TXT records describe the Two SRV records with accompanying AAAA and TXT records describe the
two services in more detail. The services share the same IP address, two services in more detail. The services share the same IP address,
are connected to the same port, but do have different paths names. are connected to the same port, but do have different paths names.
The TXT record is used to specify the path part with "PATH=". The TXT record is used to specify the path part with "path=".
id-1._occup_sensor SRV proxy.o4.b8.example.com Port-x id-1._occup_sensor SRV proxy.o4.b8.example.com Port-x
AAAA FDFD:: 1241 AAAA fdfd:: 1241
TXT PATH=/os IF=ZigBee TXT path=/os if=ZigBee
id-1._temp_sensor SRV proxy.o4.b8.example.com Port-x id-1._temp_sensor SRV proxy.o4.b8.example.com Port-x
AAAA FDFD:: 1241 AAAA fdfd:: 1241
TXT PATH=/ts IF=ZigBee TXT path=/ts if=ZigBee
sl-ts.o4.b8.example.com AAAA FDFD::1242 sl-ts.o4.b8.example.com AAAA fdfd::1242
sl-os.o4.b8.example.com AAAA FDFD::1243 sl-os.o4.b8.example.com AAAA fdfd::1243
The path names /ts and /os are short names for temperature_sensor and The path names /ts and /os are short names for temperature_sensor and
occupancy_sensor respectively and were taken over from link-format occupancy_sensor respectively and were taken over from link-format
information contained in the sleeping devices. Two AAAA records are information contained in the sleeping devices. Two AAAA records are
provided for the two sleeping devices. The proxy has used the domain provided for the two sleeping devices. The proxy has used the domain
names of the sleeping devices to subscribe to the publications of the names of the sleeping devices to subscribe to the publications of the
two sleeping devices. two sleeping devices.
It is important to remark that there are now two services with the It is important to remark that there are now two services with the
same resources present on two different devices: the sleeping device same resources present on two different devices: the sleeping device
and its proxy. When a host invokes the /.well-known/core resource, and its proxy. When a host invokes the /.well-known/core resource,
it should be possible to distinguish between the proxy (to be it should be possible to distinguish between the proxy (to be
invoked) and the sleeping device (not to be invoked). The invoked) and the sleeping device (not to be invoked). The
distinction is necessary once the sleeping device is discoverable and distinction is necessary once the sleeping device is discoverable and
the sleeping device is awake from time to time. It is suggested that the sleeping device is awake from time to time. It is suggested that
the link-format syntax allows to make this distinction. the link-format syntax allows to make this distinction.
6. Legacy data Representations in CoAP 6. Legacy data Representations in CoAP
Before CoAP devices can come to market, manufacturers must agree that Before CoAP devices can come to market, manufacturers must agree that
the type and attributes of the device can be interpreted according to the type and resources of the device can be interpreted according to
some generally recognized syntax. At this moment no such generally some generally recognized syntax. At this moment no such generally
recognized syntax exists for CoAP devices. We do not expect an IETF recognized syntax exists for CoAP devices. We do not expect an IETF
working group to standardize such a syntax, and we are convinced that working group to standardize such a syntax, and we are convinced that
syntax standardization is the responsibility of industry standards syntax standardization is the responsibility of industry standards
organizations. Given the long history of building control, many organizations. Given the long history of building control, many
groups have defined a data representation for building control groups have defined a data representation for building control
devices for example BACnet, ZigBee, oBIX, LON, KNX, and many others. devices for example BACnet, ZigBee, oBIX, LON, KNX, and many others.
It is our believe that new representations will be defined and must It is our belief that new representations will be defined and must
coexist with the named legacy ones. coexist with the named legacy ones.
The CoAP protocol should transport any data representation, and The CoAP protocol should transport any data representation, and
certainly the legacy ones. As pointed out earlier, this has certainly the legacy ones.It is expected that a CoAP client can
consequences for the naming of resources. In some cases a CoAP handle one or more legacy representation. Given that a CoAP client
device can handle more than one legacy representation. Given that a can handle representation of standard XXX, this I-D proposes that
CoAP device can handle representation of standard XXX, this I-D such a CoAP device can communicate with legacy devices via a CoAP/
proposes that such a CoAP device can communicate with legacy devices legacy gateway (router).
via a CoAP/legacy gateway (router).
6.1. Network architectures 6.1. Network architectures
+------+ +------+ +------+ +------+ +------+ +------+
| yyy | | zzz | | zzz | | yyy | | zzz | | zzz |
| link | | CoAP | | CoAP | | link | | CoAP | | CoAP |
+------+ +------+ +------+ +------+ +------+ +------+
| +---------+ | +---------+
|---------| CoAP |--> |---------| CoAP |-->
| | gateway | | | gateway |
skipping to change at page 25, line 11 skipping to change at page 24, line 39
over the yyy link. The zzz CoAP hosts, including the zzz;yyy host over the yyy link. The zzz CoAP hosts, including the zzz;yyy host
can freely exchange zzz data representations according to the CoAP can freely exchange zzz data representations according to the CoAP
protocol over the wireless 6LoWPAN network. The zzz;yyy host can protocol over the wireless 6LoWPAN network. The zzz;yyy host can
send yyy data representations to the CoAP gateway which passes them send yyy data representations to the CoAP gateway which passes them
on to the specified yyy legacy host. The yyy legacy device returns on to the specified yyy legacy host. The yyy legacy device returns
data to the requesting zzz;yyy CoAP host via the same gateway. data to the requesting zzz;yyy CoAP host via the same gateway.
The CoAP hosts can address the legacy devices behind the gateway in The CoAP hosts can address the legacy devices behind the gateway in
at least 4 ways. at least 4 ways.
- All devices of legacy network YYY share the URI-host with the CoAP - All devices of legacy network YYY share the URI with the CoAP
gateway. Every legacy device is a resource for the gateway as gateway. Every legacy device is a resource for the gateway as
seen from the CoAP host. Consequently, the CoAP host sends the seen from the CoAP host. Consequently, the CoAP host sends the
message to the IP address of the gateway and the gateway parses message to the IP address of the gateway and the gateway parses
the URI-Path to determine the specified legacy device. the URI-Path to determine the specified legacy device.
- All devices of legacy network YYY have IP addresses different from - All devices of legacy network YYY have IP addresses different from
the IP address of the gateway. Consequently, a CoAP host sends the IP address of the gateway. Consequently, a CoAP host sends
the message to the IP address of the specified device. The the message to the IP address of the specified device. The
routing protocol on the CoAP network makes the message arrive at routing protocol on the CoAP network makes the message arrive at
the CoAP gateway. The gateway determines the specified legacy the CoAP gateway. The gateway determines the specified legacy
device from the destination IP address. device from the destination IP address.
- All devices of legacy network YYY have different authorities. - All devices of legacy network YYY have different authorities. The
This means that the possibly lengthy authority names need to be authorities of the legacy device resolve to an IP address of the
transmitted. The gateway recognizes the authorities and maps gateway. This means that the possibly lengthy authority names
authority to legacy device. need to be transmitted. The gateway recognizes the authorities
and maps authority to legacy device.
- All devices of legacy network YYY have different ports. This can - All devices of legacy network YYY have different ports. This can
be expressed in two ways (1) as :port in the URI, or (2) in the be expressed in two ways (1) as :port in the URI, or (2) in the
DNS-SD records. In the latter case the port is defined in the UDP DNS-SD records. In the latter case the port is defined in the UDP
header and is efficient in packet header size. header and is efficient in packet header size.
The major advantage of all four approaches is that the gateway only The major advantage of all four approaches is that the gateway only
handles the URI or IP address and port number to select the handles the URI or IP address and port number to select the
destination legacy device independent of the type of legacy device destination legacy device independent of the type of legacy device
and the contents of the legacy payload of the message. In Figure 1 and the contents of the legacy payload of the message. In Figure 1
the gateway connects to a single link. For example, this would be the gateway connects to a single link. For example, this would be
the case for DALI standard. Other legacy standards, like BACnet, the case for DALI standard. Other legacy standards, like BACnet,
LON, allow networks composed of multiple links. LON, allow networks composed of multiple links.
An example of an invocation of a ZZZ service (See figure 2). The An example of an invocation of a ZZZ service (See figure 2). The
resource path /.well-known/ZZZ identifies the parser of the ZZZ resource path /ZZZ identifies the parser of the ZZZ syntax. A 12
syntax. A 12 octet string completely describes the ZZZ command. The octet string completely describes the ZZZ command. The host is
host is completely identified by the authority in the URI. The ZZZ completely identified by the authority in the URI. The ZZZ parser on
parser on the host is identified by the port number in the UDP header the host is identified by the port number in the UDP header (not
(not shown). shown).
Client CoAP/ZZZ Client CoAP/ZZZ
| device | device
| REQUEST | | REQUEST |
|-------- CON [0x5577] PUT /.well-known/ZZZ -------->| |-------- CON [0x5577] PUT /ZZZ -------->|
| binary 12 octet string | | binary 12 octet string |
| | | |
| RESPONSE | | RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- | |<---------- ACK [0x5577] 2.00 OK ----------------- |
| | | |
Figure 2: Sending a ZZZ command with CoAP to CoAP/ZZZ device Figure 2: Sending a ZZZ command with CoAP to CoAP/ZZZ device
An example of an invocation of a DALI legacy device behind a gateway An example of an invocation of a DALI legacy device behind a gateway
is given in figure 3. The resource path /.well-known/DALI identifies is given in figure 3. The resource path /DALI identifies the DALI
the DALI device. The application sets a value of 200 in the DALI parser. The application sets a value of 200 in the DALI device in
device in the attribute 256 defined by the DALI spec. the resource 256 defined by the DALI spec.
Client DALI/CoAP Client DALI/CoAP
| gateway | gateway
| REQUEST | | REQUEST |
|------- CON [0x5577] PUT /.well-known/DALI -------->| |------- CON [0x5577] PUT /DALI -------->|
| binary 16 bit payload dt*256 + 200 | | binary 16 bit payload dt*256 + 200 |
| | | |
| RESPONSE | | RESPONSE |
|<---------- ACK [0x5577] 2.00 OK ----------------- | |<---------- ACK [0x5577] 2.00 OK ----------------- |
| | | |
Figure 3: Sending a DALI setting with CoAP to CoAP/DALI gateway Figure 3: Sending a DALI setting with CoAP to CoAP/DALI gateway
6.2. Gateways to legacy networks 6.2. Discovery of legacy gateways
Two types of gateways are considered; (1) CoAP gateway to a single
legacy link, called yyy/CoAP gateway, and (2) CoAP gateway to legacy
network, called xxx/CoAP gateway. The source encapsulates the data
with the corresponding representation inside a CoAP message and sends
these messages to the gateway. In the gateway the XXX/YYY data is
removed from the CoAP message and transported to the desired device.
Returning an answer to the invoking host needs to be done in two
different ways dependent on the addressing type of the XXX/YYY
standard. The IP-device-identifier (INI) can be (1) the IP-address,
(2) the IP-address, port number, (3) the URI, or (4) the path .
- The packet contains a YYY link address. In the gateway two tables
are maintained. Table 1 contains a link from INI to YYY address.
Table 2 contains a link of the source IP address to the
destination YYY address for the active request. A yyy/CoAP host
with IP address, IPs, sends a request to the INI, IPd, of the
specified YYY device with link address Yd. The packet is routed
to the CoAP gateway. The gateway strips the link, network and
CoAP information from the packet and sends the message to the Yd
specified in table 1 with the (Yd, IPd) pair. The gateway stores
the source IP address with the destination YYY address in table 2
as pair (IPs, Yd). When an answer is returned from Yd, the
gateway creates a new CoAP packet with the destination address,
IPs, as found in table 2 and sends it on to the yyy/CoAP host,
IPs.
- The packet contains a XXX network address. In the gateway two
tables are maintained. Table 1 contains a mapping from XXX
network addresses to INI for all XXX devices. Table 2 contains a
mapping from IP addresses to XXX network addresses for IP devices.
The xxx/CoAP host with IP address, IPs, sends a request to the
INI, IPd, of the specified XXX device with network address Xd.
The packet is routed to the CoAP gateway. The gateway strips the
link, network and CoAP information from the packet and sends the
message to the Xd specified in table 1 with the (Xd, IPd) pair
with as source Xs as specified in table 2 with the (Xs, IPs) pair.
When an answer is returned from Xd to Xs, the gateway creates a
new CoAP packet with the destination address, IPs, as found in
table 2 with the (IPs, Xs) pair and with source address IPd as
found in table 1 with (Dd, IPd) pair. The gateway sends the
answer on to the xxx/CoAP host, IPs.
It is assumed that the gateway conforms to the core standard at the
internet interfaces. Consequently, all resources are visible at
/.well-known/core by invoking a GET. These entries can be entered
into DNS-SD with a commissioning tools as proposed in section 5.3;
according to the rules specified in section 4. Filling in the
address mapping tables is done in a similar way as done for other
Application Level Gateways (ALG).
6.3. Discovery of legacy gateways
Discovery of legacy gateways is not very different from discovery of Discovery of legacy gateways is not very different from discovery of
proxies in section 5.4. the consequences for discovery are listed for proxies in section 5.4. the consequences for discovery are listed for
the four modes of addressing legacy devices via a gateway of section the four modes of addressing legacy devices via a gateway of section
6.1. 6.1.
- The gateway presents a list of resources representing the legacy - The gateway presents a list of resources representing the legacy
devices. Discovery is done as for other CoAP devices. devices. Discovery is done as for other CoAP devices.
- Each legacy device has a different IP address. The gateway must - Each legacy device has a different IP address. The gateway must
skipping to change at page 29, line 12 skipping to change at page 27, line 32
devices behind gateways. The discovery of backward proxies of devices behind gateways. The discovery of backward proxies of
sleeping devices is handled in a similar fashion. sleeping devices is handled in a similar fashion.
A targeted resource is specified by the path portion of the URI. A targeted resource is specified by the path portion of the URI.
Again, this I-D does not mandate a universal naming standard for Again, this I-D does not mandate a universal naming standard for
resources but uses examples to show how resources could be named for resources but uses examples to show how resources could be named for
various legacy standards. An obvious requirement for resources that various legacy standards. An obvious requirement for resources that
are accessed by multicast is that they MUST all share the same path. are accessed by multicast is that they MUST all share the same path.
It is shown that it is possible to transport legacy commands (e.g. It is shown that it is possible to transport legacy commands (e.g.
expressed in BACnet, LON, DALI, ZigBee, etc.) inside a CoAP message expressed in BACnet, LON, DALI, ZigBee, etc.) inside a CoAP message
body. This necessitates the definition of an additional IANA mime body. Entering ServiceTypes particular to a given standard
code, and the mapping of legacy specific discovery semantics to CoAP necessitates that the standardization body declares the ServiceType
resource discovery messages or DNS-SD lookups. to dns.org.
8. Security considerations 8. Security considerations
TBD: The detailed CoAP security analysis needs to encompass scenarios TBD: The detailed CoAP security analysis needs to encompass scenarios
for building control applications. for building control applications.
Based on the programming model presented in this I-D, security Based on the programming model presented in this I-D, security
scenarios for building control need to be stated. Appropriate scenarios for building control need to be stated. Appropriate
methods to counteract the proposed threats may be based on the work methods to counteract the proposed threats may be based on the work
done elsewhere, for example in the ZigBee over IP context. done elsewhere, for example in the ZigBee over IP context.
skipping to change at page 30, line 21 skipping to change at page 28, line 40
From bc-02 to bc-03 From bc-02 to bc-03
- Elaboration on gateways, commissioning and legacy networks. - Elaboration on gateways, commissioning and legacy networks.
- Recommendation to extend DNS-SD naming with sn, st, and ss - Recommendation to extend DNS-SD naming with sn, st, and ss
attributes. attributes.
From bc-03 to bc-04 From bc-03 to bc-04
- moved core link extension sub-section to resource directory draft - moved core link extension sub-section to discovery mapping draft
- extended use of service type - extended use of service type
- gave DNS record examples and worked out multifunction device - gave DNS record examples and worked out multifunction device
- added proxy discovery and legacy gateway discovery - added proxy discovery and legacy gateway discovery
- defined path tree and corresponding schema - defined path tree and corresponding schema
- reviewed definition of server, service, device, service attribute, - reviewed definition of group, device, server, service (interface),
and resource resopurce, and attribute.
From bc-04 to bc-05
- extended and corrected examples for multi-function devicesw
- syntax more compatible with other resource discovery I-Ds
- abstract adapted
- more stringent use of the words server, end point, service and
devices
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
skipping to change at page 32, line 17 skipping to change at page 30, line 48
draft-cheshire-dnsext-multicastdns-14 (work in progress), draft-cheshire-dnsext-multicastdns-14 (work in progress),
February 2011. February 2011.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank, Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", "Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-07 (work in progress), July 2011. draft-ietf-core-coap-07 (work in progress), July 2011.
[I-D.ietf-core-link-format] [I-D.ietf-core-link-format]
Shelby, Z., "CoRE Link Format", Shelby, Z., "CoRE Link Format",
draft-ietf-core-link-format-06 (work in progress), draft-ietf-core-link-format-07 (work in progress),
June 2011. July 2011.
[I-D.martocci-6lowapp-building-applications] [I-D.martocci-6lowapp-building-applications]
Martocci, J., Schoofs, A., and P. Stok, "Commercial Martocci, J., Schoofs, A., and P. Stok, "Commercial
Building Applications Requirements", Building Applications Requirements",
draft-martocci-6lowapp-building-applications-01 (work in draft-martocci-6lowapp-building-applications-01 (work in
progress), July 2010. progress), July 2010.
[I-D.rahman-core-groupcomm] [I-D.rahman-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP", Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-rahman-core-groupcomm-06 (work in progress), draft-rahman-core-groupcomm-07 (work in progress),
July 2011. October 2011.
[I-D.shelby-core-resource-directory] [I-D.shelby-core-resource-directory]
Shelby, Z. and S. Krco, "CoRE Resource Directory", Shelby, Z. and S. Krco, "CoRE Resource Directory",
draft-shelby-core-resource-directory-00 (work in draft-shelby-core-resource-directory-01 (work in
progress), June 2011. progress), September 2011.
[I-D.lynn-core-discovery-mapping] [I-D.lynn-core-discovery-mapping]
Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based Lynn, K. and Z. Shelby, "CoRE Link-Format to DNS-Based
Service Discovery Mapping", Service Discovery Mapping",
draft-lynn-core-discovery-mapping-00 (work in progress), draft-lynn-core-discovery-mapping-01 (work in progress),
July 2011. July 2011.
[I-D.lynn-dnsext-site-mdns] [I-D.lynn-dnsext-site-mdns]
Lynn, K. and D. Sturek, "Extended Multicast DNS", Lynn, K. and D. Sturek, "Extended Multicast DNS",
draft-lynn-dnsext-site-mdns-01 (work in progress), draft-lynn-dnsext-site-mdns-01 (work in progress),
March 2011. March 2011.
[BACnet] Bender, J. and M. Newman, "BACnet/IP", [BACnet] Bender, J. and M. Newman, "BACnet/IP",
Web http://www.bacnet.org/Tutorial/BACnetIP/index.html, Web http://www.bacnet.org/Tutorial/BACnetIP/index.html,
2000. 2000.
 End of changes. 94 change blocks. 
407 lines changed or deleted 335 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/