One document matched: draft-dijk-core-sleepy-reqs-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.rahman-core-sleepy-problem-statement SYSTEM 
	"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rahman-core-sleepy-problem-statement.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.ietf-core-block SYSTEM
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-block.xml">
<!ENTITY I-D.ietf-core-observe SYSTEM
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml">
<!ENTITY I-D.ietf-lwig-terminology SYSTEM
  "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lwig-terminology.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-dijk-core-sleepy-reqs-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="CoAP Sleepy Device Requirements">Sleepy Devices using CoAP - Requirements</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Esko Dijk" initials="E.O." role="editor"
            surname="Dijk">
      <organization>Philips Research</organization>

      <address>
        <postal>
          <street>High Tech Campus 34</street>

          <!-- Reorder these if your country does things differently -->
          <code>5656 AE</code>
          <city>Eindhoven</city>
          <region></region>
          <country>NL</country>
        </postal>
        <phone>+31 40 2747947</phone>
        <email>esko.dijk@philips.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2013" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Applications</area>

    <workgroup>CoRE Working Group</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

		<keyword>CoRE</keyword>
		<keyword>CoAP</keyword>
    <keyword>sleepy</keyword>
    <keyword>requirements</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document provides requirements for operation of sleepy CoAP devices, based on
      	home control and
      	building control use cases. These requirements can be used to help design, or select,
      	a solution for sleepy CoAP devices in the CoRE WG. In addition, for the existing CoAP,
      	core-block and core-observe functions some notes are made on how these functions could 
      	be used in an overall CoRE sleepy devices solution that meets the requirements.
			</t>
    </abstract>
  </front>

  <middle>
  	
    <section title="Terminology">
			<t>
				For terminology regarding constrained nodes we use <xref target="I-D.ietf-lwig-terminology"/>.
				This document focuses on S0 class devices ("always-off").
			</t>
			
			<section title="Abbreviations">
				<t>
				<list>
					<t>CoRE: Constrained RESTful Environments</t>
					<t>SEP: Sleepy Endpoint</t>
					<t>NSEP: Non-Sleepy Endpoint</t>
				</list>
				</t>
			</section>

      <section title="Definitions">
      	<t>
      	<list style="hanging">
      	
      	<t hangText="Sleepy Endpoint (SEP)">: A CoAP endpoint hosted on a networked computing device,
      		which sets its network link to a disconnected state during long periods of time to save energy. 
      		"Long" means here that the period is of such duration that most messages sent to a SEP are lost 
      		despite use of
      		standard "reliable transmission" techniques. The device is S0 class and any of E0/E1/E2 class 
      		according to <xref target="I-D.ietf-lwig-terminology"/>.
      		See also the similar definition of SEP in <xref target="I-D.rahman-core-sleepy-problem-statement"/>.</t>
      	
      	<t hangText="Non-Sleepy Endpoint (NSEP)">: A CoAP endpoint hosted on a networked computing device,
      		which has its network interface in an always-connected state or operates its network interface such
      		that the endpoint(s) on it appear always-connected. 
      		The device is S1 or S2 class and any of E1/E2/E3 class as in <xref target="I-D.ietf-lwig-terminology"/>.</t>
      	
      	<t hangText="Sleeping/Asleep">: A SEP being in a "sleeping state" i.e. its network interface is
      		disconnected and a SEP is not able to send or receive messages.</t>
      	
      	<t hangText="Awake/Not Sleeping">: A SEP being in an "awake state" i.e. its network interface is
      		connected and the SEP is able to send or receive messages.</t>
      	
				<t hangText="Destination">: a NSEP to which event messages are sent by a SEP, or by a Proxy on behalf of a SEP.</t>
				
				<t hangText="Heartbeat">: a type of message (event), which is sent periodically to indicate to a Destination 
					that the sender is still operational and able to communicate to the Destination. A heartbeat message may contain
					data about the current status of the sender. Typically sent by a SEP.</t>
				
				<t hangText="Proxy">: a NSEP which is communicating directly with a SEP; able to cache 
					information/CoAP resources on behalf of SEP for the purpose of further distribution or making it accessible 
					to interested endpoints. It acts as an intermediary between a SEP and a NSEP. 
					The Proxy provides immediate/reliable connectivity, to enable NSEPs to
					operate on SEP resources even while the SEP is sleeping.</t>
      	
      	</list>
      	
      	</t><t>
      	In addition to these definitions, readers should also be familiar with
   			the terms and concepts discussed in <xref target="I-D.ietf-core-coap"/>.
      	</t>
      </section>

      <section title="Requirements Language">
      	<t>
      		Capitalized equirements language is used in this document to indicate the importance of
      		requirements. "MUST" level requirements are those required to be addressed by
      		a solution. "SHOULD" level requirements are about functionality that is preferably
      		provided by a solution. "MAY" level requirements describe optional functionality.
      	</t>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described above and in <xref
        target="RFC2119">RFC 2119</xref>.
        </t>
      </section>
    </section>
    
    <section anchor="Introduction" title="Introduction">
    		<t>
    			The CoRE WG charter includes the topic of caching resources on behalf of sleepy devices. 
    			Already, various proposals have been made in the CoRE WG with solutions to enable operation of
    			sleepy CoAP endpoints.
    		</t>
    		<t>
    			During and shortly after IETF 83 (March 2012) it was proposed 
    			to first clarify the scope and the requirements that a solution should fulfil, before choosing for or
    			developing a solution to support sleepy device operation in CoRE using CoAP.
    		</t>
    		<t>
    			This document aims to provide input to the mentioned requirement gathering and selection process. 
    			The application area that we focus on is Home Control and Building Control. The reader is 
    			assumed to be familiar with the Sleepy Devices in CoAP Problem Statement
    			<xref target="I-D.rahman-core-sleepy-problem-statement"/>. Possibly, the content of this
    			document can be input to the Problem Statement I-D.
    		</t>
    		<t>
    			First, the requirements categories and related use cases are listed 
    			in <xref target="RequirementsOverview"/>. 
    			From the use cases a set of
    			requirements was extracted, which is detailed in 
    			<xref target="Requirements"/>. Finally, <xref target="Solutions"/>
    			provides some ideas how current protocols being defined in the CoRE WG 
    			(<xref target="I-D.ietf-core-coap"/>, <xref target="I-D.ietf-core-block"/>, <xref target="I-D.ietf-core-observe"/>) 
    			can be applied to a 
    			sleepy CoAP devices solution that meets the requirements.
    		</t>
    </section>
    	
    <section anchor="RequirementsOverview" title="Requirements Categories and Use Cases">
			<t>From use cases, a number of requirements can be extracted for SEPs and for constrained 
				RESTful systems that contain SEP devices.
				<xref target="Requirements"/> will list the main requirements that we extracted.
			</t>
			
			<t>
    		This section lists a number of use cases in Home Control and Building Control, in 
    		which SEP functionality would be desired. The main driver for SEP functionality in CoAP is to 
    		achieve fully wireless, battery-operated or energy-harvesting CoAP devices that require minimal manual
    		maintenance, e.g. having a long battery lifetime.	Note that CoRE
				application domains like Industrial Sensing, Smart Energy or Smart City are not covered by
				these use cases. However, it is likely that requirements from these domains overlap to
				a large extent with those presented here.
    	</t>
			
			<t>
				The requirements are organized in the categories (Rx) shown below. Per category, some use case
				examples are provided.
				<list>
<t>R1. Report SEP->NSEP: SEP reports new information (e.g. events) to a non-SEP, or to a multicast group of non-SEPs.
<list style="symbols">
	<t>A solar-powered daylight sensor periodically measures daylight intensity in a room and reports this information to a designated NSEP or group of endpoints. For example, a local luminaire that adapts its dim level according to daylight level.</t>
	<t>An energy-harvesting light switch is pressed, switches on the radio and sends a request to a light or group of lights (NSEPs) to turn on.</t>
	<t>A battery-powered occupancy sensor detects an event of people present, switches on the radio and sends a request to one or a group of CoAP-enabled lights to turn on.</t>
  <t>Alternative to above: instead of sending directly to the light(s) the sensor sends to an intermediate CoAP node (e.g. Proxy or controller) which then carries out the request to endpoint/group(s) of endpoints.</t>
  <t>A battery-powered temperature sensor reports room temperature to a designated NSEP that controls HVAC devices. The sensor reports periodically and reports extra when the temperature deviates from a predefined range.</t>
	<t>A battery-powered sensor sends an event "battery low" to a designated reporting location (NSEP).</t>
</list>
</t>

<t>R2. Read SEP->NSEP: SEP reads (or queries) information from a non-SEP
<list style="symbols">
	<t>A sleepy sensor (periodically) updates internal data tables by fetching it from a predetermined remote NSEP, e.g. a backend server.</t>
	<t>A sleepy sensor (periodically) checks for new firmware with a remote (CoAP) endpoint. If new firmware is found, the sensor switches to a non-sleepy operation mode, starts an update procedure and new firmware is downloaded in the device.</t>
</list>
</t>

<t>R3. Read NSEP->SEP:  Non-SEP reads (or queries) information from a SEP, or from a multicast group of SEPs.
<list style="symbols">
	<t>A NSEP (e.g. in the backend) requests the status of a deployed sleepy sensor, e.g. current sensor state and/or firmware version and/or battery status and/or its error log. It expects a response within one, or at most a few, second(s).</t>
	<t>A NSEP (e.g. in the backend) requests the status of a group of deployed sleepy sensors. It expects responses even for the sensors that are sleeping at the time of doing the request.</t>
	<t>A NSEP requests information on when a sleepy sensor was 'last active' (i.e. identified as being awake) in the network.</t>
	<t>A NSEP subscribes itself to sensor events and status reports of multiple sleepy sensors for diagnostic purposes. The subscription relation is only temporary, until the diagnostic operation concludes.</t>
</list></t>

<t>R4. Write NSEP->SEP: Non-SEP writes (or configures, updates, deletes, etc.) information to a SEP
<list style="symbols">
	<t>An authorized NSEP changes the reporting frequency of a deployed sleepy sensor.</t>
	<t>An authorized NSEP adds a new reporting endpoint to an operational sleepy sensor. From that moment on, the new endpoint (NSEP) receives also the sensor events and status updates from the sleepy sensor.</t>
	<t>A remote NSEP instructs a sleepy sensor to upgrade its firmware. The sensor firmware is then upgraded. (In whatever way - the SEP may pull data from a server, or the remote NSEP may push data to the SEP.)</t> 
</list></t>

<t>R5. Transfer NSEP->SEP: Large data volume e.g. firmware is transferred into a SEP. The data originates from a non-SEP. Either NSEP or SEP takes initiative to start the transfer.
<list style="symbols">
	<t>A remote NSEP instructs a sleepy sensor to upgrade its firmware. The sensor firmware is then upgraded. (In whatever way - the SEP may pull data from a server, or the remote NSEP may push data to the SEP.)</t> 
	<t>A sleepy sensor (SEP) on own initiative switches to a non-sleepy operation mode, starts an update procedure and new firmware is downloaded in the device.</t>
</list></t>

<t>R6. Security</t>

<t>R7. Configuration, commissioning, diagnostics & maintenance
<list style="symbols">
	<t>An installer deploys a new sleepy sensor in a room. The sensor is then configured to control all lights in the room in a commissioning phase. Finally, the sleepy operation is enabled in the sensor right after the commissioning phase (i.e. start of the operational phase).</t>
</list></t>

<t>R8. General</t>

				</list>
			</t>
		</section>
    

    <section anchor="Requirements" title="Requirements">	    
    	
	    <section anchor="R1" title="R1 - SEP Reports To NSEP">
	    <t>
	    	<list style="numbers">
	<t>Reporting destination type(s). A SEP MUST be able to report directly to an endpoint or group; and to an intermediate node/Proxy that takes care of communicating to the final endpoint/group. Multiple reporting destinations MUST be supported. Rationale: direct unicast/multicast reporting is needed for high reliability, low latency, and avoiding single-point-of-failure situations.</t>
	<t>Reporting destination location. A reporting destination endpoint MUST be able to handle any addressing like: link-local, subnet-local (e.g. 6LoWPAN), site-local (typ. corporate LAN/Intranet), or global (WAN/Intranet/Internet).</t>
	<t>Reporting latency. Any report SHOULD be delivered with low latency to the final local destination. Rationale: use cases include e.g. person detection applications, actuators react within 200 ms.</t>
	<t>Reporting reliability unicast. SEP MUST be able to reliably report events in unicast. For example, a 99.9% reliability may
		be required in a specific use case.</t>
	<t>Reporting reliability multicast. SEP MUST be able to report events in multicast to a group of NSEPs, with similar reliability as is achievable by a NSEP doing a multicast.</t>
	<t>Multicast report via Proxy. It SHOULD be possible to configure a Proxy, to which a SEP reports in unicast, such that it resends the report in multicast. Rationale: to allow simplified SEPs that do not have multicast ability; or devices that do not know a priori how multicast operation needs to be done in target networks.</t>
	<t>Reporting group topology. For a multicast group it MUST be possible to place group members across multiple subnets, with routers in between. Rationale: allow for flexibility and organic IP network growth.</t>
	<t>SEP reporting configuration. A CoRE solution MUST leave the freedom to configure a SEP with reporting destination address(es) in the following ways: standard-defined, pre-commissioned, runtime configured, runtime discovered. Rationale: leave it to vendors or other SDOs how device relations are (pre)configured.</t>
	<t>Configuration of receiver of SEP events. A CoRE solution SHOULD allow a receiver of SEP events to discover group IP address(es) it has to listen to, to receive events from a specific SEP.</t>
	<t>Direct SEP subscription. A mechanism MUST be provided for NSEPs to receive events (i.e. resource updates) sent
		by a SEP directly to NSEP, during a given period. Event delivery MUST still work even if a Proxy is not available at the time of the event. Subscribing to events MUST work also if the SEP is sleeping at the time of subscribing.</t>
	<t>Proxy subscription. A solution SHOULD be provided for clients to receive events sent by a Proxy on behalf of a SEP, during a given period. Rationale: to avoid high load on the SEP due to high number of subscribers.</t>
				</list>
			</t>
			</section>
			
	    <section anchor="R2" title="R2 - SEP Reads From NSEP">
	    <t>
	    	<list style="numbers">
	<t>Read direct. It SHOULD be possible for a SEP to read from/query a selected CoAP and/or HTTP server. </t>
	<t>Sleep mode change. It is allowed that the SEP temporarily switches to an always-on mode to perform a Read task.</t>
				</list>
			</t>
			</section>
	
	    <section anchor="R3" title="R3 - NSEP Reads From SEP">
	    <t>
	    	<list style="numbers">
	<t>Read via Proxy. It MUST be possible for a NSEP to read/query designated SEP information via a Proxy. Rationale: the SEP is unavailable most of the time, making direct contact practically impossible.</t>
	<t>Multicast read via proxies. It SHOULD be possible for a NSEP to perform a CoAP multicast request to read/query a group of SEPs, or a group of proxies.</t>
	<t>Reading reported information. A client MUST be able to read the information (CoAP resources) that a SEP is currently reporting (e.g. periodically or event-based). </t>
	<t>Reading non-reported information. A client MUST be able to read information (CoAP resources) that a SEP is currently not reporting. 
	<list style="symbols">
		<t>Note: this may require that the Proxy has a specific relation to the SEP that enables it to detect when the SEP is awake, and at that moment forward the information request to the SEP for processing. </t>
		<t>Note: some information (manufacturer name) may be sent a priori by the SEP to a Proxy, while other information (error log) may be sent on demand only.</t>
	</list></t>
	<t>Read latency. The response time for a read operation SHOULD NOT differ significantly from a typical NSEP->NSEP request in the same IP network, if the information is available in the Proxy. If the Proxy needs to wait for the next SEP's wakeup, the response time SHOULD NOT significantly exceed the device's current sleep duration.</t>
	<t>Client location. A requesting client MUST be allowed to be link-local to the SEP, or subnet-local (e.g. 6LoWPAN), or site-local (typ. corporate LAN/Intranet), or global (WAN/Intranet/Internet).</t>
				</list>
			</t>
			</section>
	
	    <section anchor="R4" title="R4 - NSEP Writes To SEP">
	    <t>
	    	<list style="numbers">
	<t>Write via Proxy. It MUST be possible for an authorized NSEP to write information to or delete information on a SEP via a Proxy.</t>
	<t>Client location: see R3 client location.</t>
	<t>Write latency. The writing latency SHOULD be approximately equal to the current sleep interval duration of the SEP, or less. Rationale: while SEP is sleeping, no writing can possibly take place. Best performance is when write operation
	occurs at the next SEP wake-up.</t>
	<t>Write reliability. The write operation MUST be performed reliably. (For example, a 99% success rate may be required in a use case, with notification to the application layer about outcome of the write operation.)</t>
				</list>
			</t>
			</section>
	
	    <section anchor="R5" title="R5 - Large transfer From NSEP To SEP">
	    <t>
	    	<list style="numbers">
	<t>Sleeping mode. A SEP MAY switch its mode of operation temporarily to always-on to execute a data transfer.</t>
	<t>Buffering requirement. A Proxy MUST NOT be required to buffer an entire data object in its memory. Rationale: a firmware image will never fit entirely in a Proxy's available memory.</t>
	<t>Location of data object. See R3 client location.</t>
	<t>Transfer external trigger. There MUST be a reliable way for a NSEP to trigger a SEP into starting a large data transfer. Rationale: to cover situations where the SEP itself is in best position to initiate the transfer, e.g. acting as a CoAP/HTTP client to fetch data blocks at its own pace.</t>
	<t>Transfer latency. If a transfer is initiated by a NSEP, It SHOULD be possible for the transfer to start at the next time instant the SEP wakes up.</t>
				</list>
			</t>
			</section>
	
	    <section anchor="R6" title="R6 - Security">
	    <t>
	    	<list style="numbers">
	<t>Security level. It MUST be possible to secure communication with a SEP at a level similar to NSEP communication. (E.g., DTLS.)</t>
	<t>Bootstrap security. It SHOULD be possible to secure any communication with a SEP that is needed to bootstrap a (new) SEP into
		a network.</t>
	<t>Proxy security. The Proxy MAY be a trusted device. That is, end-to-end CoAP security from SEP to Destination is NOT REQUIRED if a Proxy
		 is used in the communication process.</t>
	<t>Write Authentication and Authorization. When information/resources on a SEP are being written or deleted, it MUST be possible 
		for a SEP (or its Proxy) to authenticate the writer and to check that it is authorized to do so.</t>
	<t>Read/subscribe Authentication and Authorization. When information/resources on a SEP are being requested, it SHOULD be possible 
		for a SEP (or its Proxy) to authenticate the reader/subscriber and to check that it is authorized to read.</t>		
				</list>
			</t>
			</section>
	
	    <section anchor="R7" title="R7 - Configuration, commissioning, diagnostics, maintenance">
	    <t>
	    	<list style="numbers">
	<t>Configurable sleep interval(s). The sleep interval (i.e. heartbeat interval) MUST be fully configurable per sleepy node. A wide range of values (seconds, minutes, hours, days) SHOULD be supported. Variable sleep intervals SHOULD be supported. Multiple sleep intervals (such as a different interval for each sensor resource attached to an endpoint) MUST be supported.</t>
	<t>Discoverability. There MUST be one or more ways defined for a NSEP to establish the existince of a SEP and to find the IP address to contact the device (either directly or its Proxy). Note: possible ways may be DNS discovery, Resource Directory, IP address(es) derived from hardware identifier, pre-commissioned, standard-defined, etc.</t>
	<t>Discoverability 2. There SHOULD be a way to discover all proxies in a given network scope (e.g. link-local, subnet-local, site-local) and to find out which SEP they are representing.</t>
	<t>Portability. A SEP SHOULD be able to be relocated to a new physical position, while keeping its existing association to an IP subnet or PAN, without requiring any reconfiguration of the SEP and/or NSEPs/proxies it communicates with. </t>
	<t>A Proxy caching information from a SEP MAY be configured to store additional computed information based on past resource values, e.g. an average, standard deviation, history graph, etc.</t>
				</list>
			</t>
			</section>
	
	    <section anchor="R8" title="R8 - General">
	    <t>
	    	<list style="numbers">
	<t>Optional reliability. It MUST be possible for a SEP to optionally use Confirmable (CON) CoAP messaging.</t>
	<t>Cached resources freshness. Having a different Max-Age (freshness duration) per resource MUST be supported.</t>
	<t>Wake-up triggers. Wake-up based on a timer trigger, wake-up based on an (unpredictable) event trigger (e.g. sensor based), and a combination of both all MUST be possible.</t>
	<t>Local Proxy. A SEP MAY rely on the presence of at least one "parent/Proxy" device in radio range.</t>
	<t>Reception windows. A SEP SHOULD enable a radio reception interval at least once every interval it is awake.</t>
				</list>
			</t>
			</section>
	
	    <section anchor="R9" title="R9 - Non-functional requirements">
	    <t>
	    	<list style="numbers">
	<t>Implementation complexity. A solution SHOULD have minimal implementation complexity on the SEPs. Even if this implies shifting additional complexity to the clients/proxies. Rationale: sleepy sensor devices are expected to be more constrained along multiple resource axes (RAM, ROM, MCU, energy).</t>
	<t>Configuration effort sleepy. A solution SHOULD operate with minimal configuration effort of SEPs.</t>
	<t>Configuration effort proxies/clients. A solution SHOULD operate with minimal configuration effort of non-SEPs, keeping in mind that both configuration effort and implementation complexity for SEPs should be minimized with higher priority. Rationale: SEPs are typically harder to configure once deployed, due to frequent/unpredictable sleep periods.</t>
	<t>Network load. A solution SHOULD introduce minimal extra network load (number of messages, message sizes, etc.)</t>
	<t>Battery life. A CoRE SEP solution SHOULD aim to provide as long as possible battery life for SEPs. Battery life of non-SEPs is assumed to be of minor importance.</t>
	<t>Scalability. Number of devices that can subscribe to events from a single SEP SHOULD be as high as possible.</t>
	<t>Adaptability. SEPs SHOULD be aware, or made aware, of any relevant network configuration changes.</t>
	<t>NSEP communication effort. The "effort" a NSEP has to spend on communicating with SEPs SHOULD be minimal. Note: "effort" here includes complexity, need for protocols in addition to core-coap, number of transactions/messages needed, waiting time, etc.</t>
				</list>
			</t>
			</section>

		</section>

		<section anchor="Solutions" title="CoRE Building Blocks in a Sleepy Devices Solution">
			<t>
			In the CoRE WG there are various functions, or "building blocks", being developed that could be applied
			in a CoRE sleepy devices solution. 
			
			<list style="symbols">
				<t><xref target="I-D.ietf-core-coap"/> CoAP proxy: can possibly be re-used to implement the role of
					Proxy as defined in this document. However, this could require adding some special functions/measures
					to deal with SEPs. Currently a CoAP proxy will have the problem that it may 
					not reach the SEP for prolonged periods of time, e.g. to forward a CoAP request or a CoAP+observe 
					request to the SEP.
				</t>
				
				<t><xref target="I-D.ietf-core-observe"/>: the core-observe paradigm and subscription + notification 
					syntax can possibly be re-used to meet the subscription/notification requirements. A problem to
					solve is that a CoAP client is unable to perform an observe request to a SEP,
					 since it is likely to be sleeping at the time the request is made. In worst case, the SEP can never be 
					 reached by the client.
				</t>
				
				<t><xref target="I-D.ietf-core-block"/>: can be used for implementing the requirements R5 (Large transfers,
					<xref target="R5"/>). 
					However, a blockwise POST or PUT initiated by a NSEP can not be immediately used, again
					due to the reason that the SEP is likely to be asleep at the time(s) the NSEP sends its request.
				</t>
			</list>
			</t>
		</section>
		
    <section anchor="Acknowledgements" title="Acknowledgements">
			<t>Thanks to Peter van der Stok and Sye Loong Keoh for reviewing the text.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>This document includes no request to IANA.</t>
		</section>

    <section anchor="Security" title="Security Considerations">
      <t>This document contains requirements for solutions, including security requirements
      	(<xref target="R6"/>). Refer to <xref target="I-D.ietf-core-coap"/> Section 11.2 for
      	security considerations on (caching) proxies. This is very relevant as the
      	requirements indicate that use of a caching proxy may be necessary.</t>
    </section>
    
  </middle>


  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;
      &I-D.ietf-core-coap;

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
			&I-D.ietf-lwig-terminology;
      &I-D.rahman-core-sleepy-problem-statement;
      &I-D.ietf-core-block;
      &I-D.ietf-core-observe;


    </references>

  </back>
</rfc>